binary data communication through SerialPort
-
wrote on 29 Nov 2015, 19:28 last edited by
That Terminal example is exactly what I have tried, and then I got the conclusion that QSerialPort Class cannot talk to it; I assume that is because of the failure of binary communication, however not sure about it.
All I know is, serialRead() was never activated even though serialWrite() has been gone through again and again.
Here is cited by Cypress Forum about CY5670 dongle communication:
"Since the communication uses binary codes Putty is propably not the right tool. Maybe use RealTerm, IIRC it has a mode the send and receive binary data. And I think you need to send the correct data to the dongle to answer. Maybe there is some command sequence to get a version number?"It is sure that Putty could not talk to the dongle, while QSerialPort is similar to Putty.
Could anyone help me find a solution to talk to the CY5670 dongle?
Thank you!
-
wrote on 29 Nov 2015, 19:35 last edited by koahnig
Every comms in serial is basically binary. It will not know a difference.
In most cases it is a baud rate respectively other settings issue. I guess that is also the issue with Putty.
Do you have the correct baud rate, data and stop bits and otzher flags? -
Hi
Im not sure what you mean by binary communication.
But QSerialPort can handle all that a com port can send.When data comes in Terminal Example
Its read into a byte array which can handle binary just fine.
But the PutData calls
insertPlainText(QString(data));And if its not printable as text, it might become nothing. (shows nothing)
So first check is to see if readData() is called.
If dongle has protocol, it might expect you to send something to it before it
sends anything.void MainWindow::readData()
{
QByteArray data = serial->readAll();
console->putData(data);
qDebug() << "Its alive"; /// to test its called
} -
Every comms in serial is basically binary. It will not know a difference.
In most cases it is a baud rate respectively other settings issue. I guess that is also the issue with Putty.
Do you have the correct baud rate, data and stop bits and otzher flags?wrote on 29 Nov 2015, 19:41 last edited by@koahnig said:
Do you have the correct baud rate, data and stop bits and otzher flags?
Yes, I am sure those are correct.
The dongle is controlled by command packets. And any wrong command packets should active a error response, which I never received; the serialRead() was never called.
-
well I would try with
http://realterm.sourceforge.net/ then and see if it even works at all. -
wrote on 29 Nov 2015, 20:11 last edited by mrdebug
Have you tried the QThread approach instead of events?
Please, download this
http://kde-apps.org/content/show.php/QtComPort?content=142378
and have a look at the file qthcomport.cpp
I know everybody don't like the QThread approach instead of events but in a difficoult situation I think the QThread approach is better. You can manage timemouts an polling.
Have you got the dongle serial protocol?
Every serial device has a protocol. For example if you send at a modem at&v you will have the current modem configuration.
Often the serial devices have a command to know the firmware version. This is the first command to implement. Normally there are a byte to begin, end and control.
Have you found the serial protocol in the sdk? -
Hi,
Maybe a silly question but are you sure this dongle can be used like a serial port ? The description says BLE to USB bridge.
-
wrote on 30 Nov 2015, 07:15 last edited by
I think the same thing. I normally use ble with bluez ( the Debian bluetooth stack) and not the usb dongle directly. Maybe his usb dongle has the bluetooth stack embedded.
-
@Sen-Li
congratulation! -
Nice, what was the problem ?
On a side note, you don't need to modify your thread title anymore, just use the "Topic Tool" button to mark the thread as solved :)
-
wrote on 30 Nov 2015, 22:50 last edited by
That CY5670 BLE dongle discards any commands without a header, which means I need to add a header to my command packet to talk to the dongle, otherwise nothing will happen.
-
Thanks for sharing your findings :)
13/16