Hi Tom:
Thanks again for a great set of products!
I'm experimenting with getting the suggested Adafruit bluetooth interface running with the popular QCX-mini. Eventually I'd like this to work with the iPad version, but for now I'm starting simply with the Macbook version.
I'm monitoring all data transactions with my Siglent1204xe scope in decode mod, and I think I've found a problem. Perhaps I'm not understanding the TS480 specification properly?
I'm having some success in that RumlogNG reports the QCX-mini VFOA setting and displays it correctly. This works reliably.
If I type 14230<enter> into the callsign field, the QCX VFOA does not change however.
When I look at the transmitted data, you do not appear to be sending the trailing digits of the frequency, nothing is sent after the "230". Both the TS-480 manual I have and the QCX manual indicate that there should be another 3 zeros (for an 11 digit frequency command) followed by a semicolon.
I've confirmed that the Mac and the bluetooth interface have no problem sending very long ascii strings without dropping any data when I send them myself from a terminal program. The protocol internally handshakes the BLE uart protocol perfectly and the scope captures them all just fine.
Is this a bug?
thanks in advance,
Mario AE0GL
Edited 23-Nov-2021:
I have some additional info for you.
By experimenting with some other RumlogNG operations, I have confirmed that the problem is being caused by the output messages being truncated at 10 characters long. This occurs on keyer "KY" messages as well. Only 10 characters are being sent.
The transmit buffer size in your bluetoothLE library (or in the MacOS itself) is probably too small and the write is being truncated. Unless your library reports the error correctly, you may not be noticing the problem. It probably doesn't happen on the USB serial device.
Depending on your programming library and language, you may be able to increase the buffer size when you open the device, or the fix may be as simple as detecting the number of characters successfully sent and hanging around to resend the rest a few milliseconds later. Many API's allow you to do this gracefully. Fortunately for this case, the messages are short enough and infrequent enough that there are easy fixes.
Another possible solution would be to send a few characters, delay and then send a few more as needed.
Hope this additional info helps - I'd love to see this working, and it's so close that I hope you can get around to fixing it soon.
Note also that I'm testing this on MacOS 10.14.6 Mojave on a 15 inch macbook pro. Other releases may have slightly different behavior.
On the iPad, I don't know if the "Generic" Kenwood support does anything useful or not - I haven't dug into seeing why it doesn't appear to do anything at all...
M
Edited 1-Dec-2021
I've confirmed that this problem only occurs with Bluetooth LE interfacing. A normal USB/Serial converter has no problem. It would still be nice to get it working...
thanks again
M