Discussion and findings

[Ylianst]

Hi. I have two of these radios and I really like this project. In my view, this opens up a lot more options for using these radios. I tried my hand at sending my own commands and have findings & questions.

• First is the event registrations. I send "EVENT_NOTIFICATION" with a body of 0x01 and it works. I tried a few different values (0x00, 0x02, 0x03, 0x04, 0x0F, 0xFF). So Far, only 0x01 and 0x08 work. I tried sending 2 bytes like 0x0001 and that does not work. I get what looks to be an error response when I try these.
• I am interesting in getting the channel_id when I receive a DATA_RXD. So far, I have not seen a channel ID in any of my messages. Any idea how to enable this? It looks like the module app does know what channel a data fragment came on.
• For sending data fragments. I am trying in C# in Windows and not hitting any issues so far. I have not tried long strings of data fragments yet, just single (less then 50 byte) and it's working for me so far.

In general, I am a lot more interesting in the full Bluetooth API than the KISS TNC which is very limiting. So, this is really amazing to see an attempt at documenting this API. This radio is ahead of the game.

[khusmann]

Hi @Ylianst , thanks for your interest!

1. What do you mean about sending "EVENT_NOTIFICATION"? As far as I know, EVENT_NOTIFICATION is only sent from the radio to the client. I've never seen the app send a "EVENT_NOTIFICATION" message to the radio, it only receives them.
2. Unfortunately I've never seen the app use the channel_id arg on DATA_RXD. The app simply tracks what channel is currently active by listening for HT_STATUS_CHANGED events to keep track of the current active channel. You can do the same in benlink by reading RadioClient.status.curr_ch_id when you receive a DATA_RXD (just realized I didn't expose that property in the RadioClient -- latest commit should fix this)
3. Yes, that makes sense -- the absolute limit will depend on the MTU of the BLE connection (not sure what the defaults are), but the app breaks up messages into frames about 50 bytes and then queues the fragments. I'll get around to implementing that one of these days, but feel free to submit a PR if you get around to it before me :)

[Ylianst]

Thanks @khusmann

1. Apologies, I meant "REGISTER_NOTIFICATION", not "EVENT_NOTIFICATION". I tried to register a few different ways and using 0x01 is so far, the way to go.
2. Yes, that makes sense. I have been tracking RadioClient.status.curr_ch_id and it seems to always point to the last channel traffic was received on. Thank you for that. Really, that is why I was testing various REGISTER_NOTIFICATION values, but curr_ch_id solves my problem.
3. Ok, got it. I want to try sending a very large amount of data between by two radios and see how it behaves. I do wonder how flow control works out over Bluetooth so not to send too much data to the radio. If you have any info on that, it would be great.

Again, this is amazing. Other manufacturers should follow with this Bluetooth API model.

[Ylianst]

Oh! I did want to ask. There is a lot of DMR related stuff in this API, but my radio UV-Pro obviously does not have DMR. Is there a radio compatible with this API available with DMR? - Thanks.

[khusmann]

Apologies, I meant "REGISTER_NOTIFICATION", not "EVENT_NOTIFICATION". I tried to register a few different ways and using 0x01 is so far, the way to go.

Ah yeah, REGISTER_NOTIFICATION is weird -- the app only ever sends is 0x01, and it seems to enable everything... Does 0x08 have any effect?

Ok, got it. I want to try sending a very large amount of data between by two radios and see how it behaves. I do wonder how flow control works out over Bluetooth so not to send too much data to the radio. If you have any info on that, it would be great.

Yeah, long messages are broken into pieces in the same way that they do in received messages -- you get a sequence of fragments ending with a final fragment with the is_final_fragment flag set.

Again, this is amazing. Other manufacturers should follow with this Bluetooth API model.

Thanks! I agree, I'd love to see other manufacturers providing similar bluetooth interfaces that we can hack on. Even better if they just released the API and we didn't have to decode it ourselves...

There is a lot of DMR related stuff in this API, but my radio UV-Pro obviously does not have DMR. Is there a radio compatible with this API available with DMR? - Thanks.

Nope, haven't found a device that supports DMR -- but it's supported by the app, as you can see by my work. If you can figure out which device in the wild does, please lmk! The only devices I'm aware of are listed on the front page:

• BTech UV-Pro
• RadioOddity GA-5WB
• Vero VR-N76 (untested)
• Vero VR-N7500 (untested)
• BTech GMRS-Pro (untested)

[Ylianst]

So, REGISTER_NOTIFICATION did not send me the same error message with 0x08, but it did not work at all. I get no notifications. So, I did not go any further. 0x01 does seem to be the only value that really works.

For fragments, yes, I assemble them the same way you do. I just did not work to fragmenting yet for outgoing traffic, but I will probably work on that this weekend. I really want to try my hand at larger file transfers and see how fast I can get it. My question was more with outgoing TNC traffic and how flow control works.

I had already searched for all the radios in your list and searched for DMR is all the specification web pages for each radio and came up empty. It's probably an upcoming feature and that is great news.

FYI. Based on your decoding work, I have been working on a Windows app that does APRS/SMS/Terminal... Once it's minimally working, I will push it as open source on GitHub. I went to a HAM meeting a few days back and demoed an early version.

Oh, I also wanted to ask. Any way to get the current GPS location of the radio? - Thanks

[khusmann]

So, REGISTER_NOTIFICATION did not send me the same error message with 0x08, but it did not work at all. I get no notifications. So, I did not go any further. 0x01 does seem to be the only value that really works.

Hmmm did 0x00 give an error? Or maybe 0x01 toggles notifications? It seems weird if you can only turn them on and there's no way to turn them back off. The app doesn't give many hints, it just sends 0x01 one time and that's it.

My question was more with outgoing TNC traffic and how flow control works.

Yeah, outgoing TNC traffic is exactly the same as incoming, as far as I've seen.

I really want to try my hand at larger file transfers and see how fast I can get it.

I think speed will be limited by the modulation of the data -- I'd expect the transfer rate to the device to be very fast compared to the packets going over the air.

It's probably an upcoming feature and that is great news.

Hmmm, I'm not so sure... I think it's more likely a radio out there we haven't found yet. But fingers crossed for it being an upcoming feature!

FYI. Based on your decoding work, I have been working on a Windows app that does APRS/SMS/Terminal... Once it's minimally working, I will push it as open source on GitHub.

Very cool! I'd love to see it when you're ready! This is exactly the sort of thing I was hoping benlink would inspire. If you found my work helpful, I'd appreciate if you credit/link back to this project when you publish to help others find it & raise awareness -- similarly, I'd be happy to add a link to your project as well!

Oh, I also wanted to ask. Any way to get the current GPS location of the radio? - Thanks

Not that I've seen! The HT app only sets the position of the radio's GPS via SET_POSITION... it never gets the radio's position, unfortunately... (it's still possible one of the unexplored cmds does this though, lmk if you find anything...)

[Ylianst]

For the outbound flow control, since Bluetooth is likely going to go a lot faster than 1200 baud packets, I expect the radio to "push back" and hopefully give me a signal when the buffer is free for more frames. In any case, I will get to this at some point. I need to get all the basic stuff working.

For credits, yes! I will not be shy to promote and link your page. I will send you an about box screenshot so you can give feedback ahead of release. My project would not exist without your work and so, it's on top of the list. I could still enable regular TNC support and probably will, but this integration makes it so much better. I will post back on this.

For GPS location, that is too bad. Unlike phones, laptops do not generally have GPS location and that would be really nice to have. I would add it to the map and could compute distances to other stations, etc. No worries, I will do without for now.

I just spend the last 6 hours+ just building the UI and support for editing channels. It was a huge amount of work, but got it working.

[khusmann]

I expect the radio to "push back" and hopefully give me a signal when the buffer is free for more frames.

Exactly. I wonder if you'll get a ReplyStatus with "INSUFFICIENT_RESOURCES", and then a "SUCCESS" when it's ready again -- I'm looking forward to hear the results of your tests!

For credits, yes! I will not be shy to promote and link your page. I will send you an about box screenshot so you can give feedback ahead of release.

Fantastic! Really appreciate it!

For GPS location, that is too bad. Unlike phones, laptops do not generally have GPS location and that would be really nice to have.

I agree!

(As I looked through the messages again I just was reminded there's a CANCEL_NOTIFICATION message -- so that's likely how to turn notifications on and off)

I just spend the last 6 hours+ just building the UI and support for editing channels. It was a huge amount of work, but got it working.

Very cool! I'm super excited to try it out when it's ready!

[Ylianst]

I drove 30 minutes today to get within reach of a local BBS and right away starting seeing packets I did not expect. My AX.25 decoder is terrible and needs to be improved. I figured it would be nice to have a packet dump for my own use, but after working on it for a bit I realized this should be a feature of the tool, not something I try to hide. So yes, mini-Wireshark.

On working on this, I realize that adding the channel id on my outbound packets is probably super important. Could it be that is the point of having a Channel ID for fragments? It's not for inbound, it's for outbound.

Seems like I am going to need a more serious AX.25 stack if I am going to do connected sessions. Having the packet trace is going to help a bunch.

[Ylianst]

@khusmann - About box. Let me know if it's ok with you. I will add similar text to the Github repo.

[khusmann]

On working on this, I realize that adding the channel id on my outbound packets is probably super important. Could it be that is the point of having a Channel ID for fragments? It's not for inbound, it's for outbound.

When I first saw the channel ID in the fragment api, I thought it would be used for the digital mode -- so outbound packets could be sent over a the digital channel, and similarly inbound would be noted as such if received from a different channel. But yeah, the official app doesn't do this, as far as I have seen in my captures -- it changes the current channel and changes back, never using the channel_id arg in the fragment either outgoing or incoming.

Have you tried sending fragments with the channel_id set? Even if it works now I probably wouldn't trust it long term because the app doesn't use it so it's a toss up if that code path is actively maintained in the firmware.

Another possibility could be dual channel mode? I haven't looked into the behavior there yet.

About box. Let me know if it's ok with you. I will add similar text to the Github repo.

Looks great! Can you add my callsign (KC3SLD) and point the link directly to the benlink project page? https://github.com/khusmann/benlink Thanks!

[Ylianst]

@khusmann Thanks for the info on channel_id, ok, still stuff to explore. I have not tried to use it yet. I released the application on GitHub: https://github.com/Ylianst/HTCommander. I will make the changes to the about box now.

Ok, new version coming up:

[Ylianst]

@khusmann I invited you as contributor. No obligation to do anything. I only have two UV-Pro radios and so, can't try any other ones. If you have one that is not UV-Pro, please give it a try. Thanks.

[khusmann]

Fantastic work! Unfortunately I only have UV-Pro as well -- please let me know if you hear from folks using other radios...

[TheCommsChannel]

This looks awesome! Quickly tried it with my UV-PRO and VR-N76, but it the window closes shortly after hitting connect. I'll try some more later this week when I get a chance to.