Skip to content
  • Qt/QML app and FPGA

    Unsolved Mobile and Embedded
    3
    0 Votes
    3 Posts
    90 Views
    jsulmJ

    @Sajjad-Ali Start here: https://doc.qt.io/qt-6/qudpsocket.html
    You will also find links to example applications there.

  • 0 Votes
    5 Posts
    139 Views
    timob256T

    @timob256 this work

    QString data_str = QString::number(data_x)+ " "+QString::number(data_y); out << data_str; qDebug() <<data_str ;

    введите сюда описание изображения

  • 0 Votes
    3 Posts
    454 Views
    timob256T

    @timob256

    Perhaps it was necessary to connect
    #include <QtNetwork>

    previously, the header was without

    #include <QtNetwork>

    now it looks like this

    #include <QMainWindow> #include "qcustomplot.h" #include <QtNetwork> #include <QHostInfo> #include <QNetworkInterface> #include <QUdpSocket> #include <QAbstractSocket> #include <QHostAddress> #include <QTime> #include <QTimer> #include <QVector> #include <QtMath>

    However, he does not transmit much data yet ж_ж

  • 0 Votes
    3 Posts
    164 Views
    C

    If something else sends a UDP datagram to the sub-net IP broadcast address (e.g. 192.168.1.255 on IP subnet 192.168.1.0/24) then any device connected to, and configured for, that IP sub-net should receive the datagram. You need to know the port that the UDP datagram was sent to also.

    Assuming your listeneing device is connected to the relevant physical network and has suitable IP address/subnet mask, then all you should need is to QUdpSocket::bind() to your IP and port.

  • 0 Votes
    6 Posts
    419 Views
    L

    Hi,
    @SGaist
    @Kent-Dorfman

    I tried to google "QUdpsocket priority",
    I got many result that discribe my problem but without soultion.

    Many peopele have the same problem.

    My felling is there is some problem. But i dont have enough knowledge to debug it.

  • 0 Votes
    7 Posts
    644 Views
    Christian EhrlicherC

    @Lior said in Signal inside readyread of QUdpsocket:

    why the UI main thread stoped to respond ? the msleep is in anthor thread.

    Because you do it wrong (and I would guess the msleep is not in the thread but in the gui thread) but without code...

  • 1 Votes
    1 Posts
    427 Views
    No one has replied
  • 0 Votes
    1 Posts
    302 Views
    No one has replied
  • 0 Votes
    2 Posts
    1k Views
    K

    Why do you want to "display it in my map using one MapQuickItem only"? You will need to create multiple MapQuickItem instances to display multiple markers on map at once. You can create them statically (if their number is known in advance) or dynamically (if not).

  • 0 Votes
    4 Posts
    491 Views
    T

    @JonB you might be right.
    http://www.informit.com/articles/article.aspx?p=1405552&seqNum=4
    in fact I could see that if there is pending datagram, read it, and then again, and as well process after each if statement. Ok. I understand it now.

  • 0 Votes
    5 Posts
    3k Views
    D

    @Xando On windows, this did not work for me, even fixing the socket options to the windows equivalent. What did work was:

    udpSocket = new QUdpSocket(this); groupAddress4 = QHostAddress(multicastAddr); bool result = udpSocket->bind( QHostAddress::AnyIPv4, port, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint);
  • 0 Votes
    9 Posts
    4k Views
    Pablo J. RoginaP

    @gsharma Ok, I forgot to mention my test environment, sorry about that.
    Well, maybe it's a good reason to update your Qt version...
    Best regards.

  • 0 Votes
    9 Posts
    2k Views
    ChristianMonteroC

    @Diracsbracket I think it should, let me try it, thanks you so much for your time!

  • 0 Votes
    4 Posts
    1k Views
    ChristianMonteroC

    @ambershark Thank you very much for your help, now it's working, it seems like I was passing the IP argument incorrectly, now I know that I have to send this parameter inside a QT function. thanks!

  • 0 Votes
    3 Posts
    2k Views
    ChristianMonteroC

    @juanki sí, de hecho al final encontre que mi error era porque la IP la tenia que mandar dentro de un método de la librería, igual gracias por tu post :)

  • UDPSocket Stopped Working

    Unsolved General and Desktop
    6
    0 Votes
    6 Posts
    2k Views
    mrjjM

    @M4RZB4Ni said:

    Hi
    When you dont have
    uSocket = new QUdpSocket(this) ;
    then
    uSocket->writeDatagram(xx
    will crash.
    as uSocket just point to random location. (dangling pointer)

    Next:
    QByteArray *priPackNuser; <<< also just a pointer.
    You should do ( as @SGaist mention)
    QByteArray priPackNuser;
    ( no *, means its real bytearray, not a pointer to one)
    So you change it from heap allocation to stack allocation.

    If you dont change to non pointer then you need
    QByteArray *priPackNuser = new QByteArray ;
    as else its a dangling pointer too!
    But no need for pointer to QByteArray here.

  • 0 Votes
    3 Posts
    5k Views
    Jesse KaukonenJ

    @kshegunov said:

    I advise benchmarking the code. For one a datagram will always arrive whole (not like with TCP where you can have the message chopped in pieces), but there's a maximum size to it. Also there's no reception notification (like with TCP) as UDP is a "connectionless" protocol. These two things in mind you either send the datagram or not, you can't have anything else returned for the written bytes.

    I suspected as much. Good to know.

    QByteArray datagram; // ... Insert size checks here as well! PendingCompressedFrame & frame = *reinterpret_cast<PendingCompressedFrame *>(datagram.data()); // No copying, valid while the byte array is still there.

    As of yet, the receiver's processing time hasn't been a bottleneck so I haven't looked into optimizing it (it completes in around 0-1ms). Thank you for the suggestion though.

    Additionally, why the mutex? What are you protecting with it exactly?

    The mutex is not needed there. There's some other data that is being accessed from a DLL from a separate thread, but I should have removed the mutex from the simplified receiver.

    One good way to deal with such throughput is to have a dedicated thread for the reception that'll put the received datagrams (no processing) into a thread safe queue (or you can also use a signal-slot connection). From there you can have another thread that orders them (they may not come in the order of sending) and ultimately preparing them for display.

    That's a good idea. Keep readyRead() as minimal as possible to get data out of the socket's buffer, allowing more data in.

    The biggest question I'm still wondering is the performance of writedatagram. I've been looking into the assorted socket options, but it will take some reading to really understand what's going on with each flag.

  • 0 Votes
    11 Posts
    4k Views
    V

    OK, I use two sockets now.
    On App A I have one socket for sending the broadcast message, and a second one on another port for receiving the answer.
    Same on App B. One socket for receiving the broadcast message and a second one for sending the answer on a different port.

    Still would be very happy if someone can find a solution for this using only one udp socket.

  • 0 Votes
    1 Posts
    2k Views
    No one has replied
  • 0 Votes
    3 Posts
    2k Views
    D

    @TioRoy Obrigado pela resposta. Acabei fazendo com a biblioteca ffmpeg, pois consegui buscar os dados e jogar pra fora em multicast mas fica travando, estou errando em algum lugar.