khusmann
GPS support
I wanted to start a discussion here to form a strategy for asking BTech to add a feature to the firmware to request GPS location from the radio.
As previously discussed here, as far as we can tell it is not possible to request a GPS location update from the radio. This is unfortunate, because when operating with a laptop (or raspberry pi, etc), it'd be really nice to use the radio's GPS. (Note that HT_STATUS_CHANGED events and GET_HT_STATUS messages return a boolean indicating if the GPS is locked, but no GPS measurements).
In the past, BTech has been really responsive to community requests (for example, there was a lot of requests for KISS support, which they added). So I think if we can get the community to ask for this feature, there is some chance BTech will listen and get it added to the firmware. Time is of the essence, because who knows how long they will continue making firmware updates...
The challenge with this request to BTech is that it's really a developer rather than a user-facing feature... Not to mention a feature in their internal API... So I haven't tried reaching out myself yet because I'm a little worried what the response will be.
The other reason I've hesitated is because I figured it'd be a drop in the bucket without the community mobilized around it, as we did with KISS. But with @Ylianst shiny new HTCommander we now have a more user-facing app that we can use to make the argument that this feature is needed.
What are y'alls thoughts on how we can get some momentum behind this request to BTech? @TheCommsChannel do you think this would be of any interest to your audience? @na7q any thoughts?
Also tagging @georges because of his work getting the CAT control code extensions supported by their KISS implementation: https://github.com/islandmagic/kiss-tnc-hw-cmd
Perhaps we could ask for another KISS extended control code to get the radio's position? This would prob be easier conversation to have than to ask for than for them to add something to the internal API...
Thoughts?
Hi @khusmann. I am glad you started this, I certainly on board with this and may just go ahead and try to reach out to BTech/VGC and see. My current wish currently is as follows:
- Read GPS Position thru the Bluetooth interface.
- Read GPS time thru the Bluetooth interface.
- Have FX.25 built-into the radio (if not already present, I imagine it's not) or...
- Alternatively allow receive/send FX.25 frames (AX.25 with forward error correction) thru Bluetooth.
- Faster data speeds, 4800 or 9600 baud data rates.
The GPS location may have some privacy implications and so, it's possible an optional opt-in on the radio would be needed, not sure. Getting GPS time is because I intend to put a message authentication protocol in HT Commander and need to HMAC the message with somewhat accurate time. For FX.25, I am not asking the radio to support it, but with a small change to the firmware, the radio would send/receive these frames and the PC would perform Reed Solomon so the radio would not have to. This would improve the reliability of the packets by a lot. Direwolf supports it.
In general, I think this is the future. This Bluetooth protocol is a game changer for usability and I hope other vendors follow along. This radio brings the hobby into the modern times. We could ask for a KISS extension, but I just love to much being able to see and control the radio fully, it's so nice.
Thank you for starting this discussion. Being able to get the GPS location from the radio would be great and is possible with a number of other radios. Getting the time would be great too, especially for JS8CALL while off-grid. I'm in contact with the firmware developer and can reach out. They may be slow to respond due to the holiday, however.
Good thread. FWIW, I think expanding on KISS hardware command is not the right path. The QSY command is kind of a hack which makes sense in the context of TNC but not much more. Cramming other unrelated things feels wrong.
Ideally we'd have an interface similar to https://github.com/LA3QMA/TH-D74-Kenwood that exposes all the radio functionality and a way to get in/out of KISS mode.
@georges I agree KISS extension is not the way to go - just including it here as a success story of BTech responding to community input. (so maybe a direction they'd consider again)
Re: Exposing all radio functionality... That is mostly solved, actually! I've reverse engineered a good portion of the native BLE / RFComm protocol, and it's all documented with a nice async python interface in this repo (benlink) You get full control over the radio, and I have full audio support coming soon. Also be sure to check out @Ylianst's C# implementation in HTCommander
So yeah, all BTech needs to do is add it to their firmware, we've got the rest covered. The question is, how do we go about asking for an upgrade to their internal API? I'm wondering how they'll react... Should we just go for it?
@Ylianst Nice list there -- @na7q has been keeping one as well (please post it here when you have the chance!). I've been thinking for a while it'd be nice to start a community wish list so we can rank them and present somewhat of a unified front in asking for these features... is that something y'all would support?
In general, I think this is the future. This Bluetooth protocol is a game changer for usability and I hope other vendors follow along. This radio brings the hobby into the modern times.
I agree!
Hi all, exciting news -- after getting referred through one BTech support person after another over the last few months, I got connected with someone at Benshikj who said he's going to try to put this in the next firmware version.
I'm trying to not get my hopes up, but this is good progress!
Benshikj came through for us!!! We now have a GET_POSITION command in the latest beta firmware (0.8.5). I have a reference implementation in the dev version of benlink here:
Protocol: https://github.com/khusmann/benlink/blob/main/src/benlink/protocol/command/position.py RadioController API: https://benlink.kylehusmann.com/benlink/controller.html#RadioController.position
Woohoo!!!!
(@Ylianst please let me know if / when you implement in HTCommander and if you find any issues you want me to pass on to Benshikj! The more testing we do now before they make a stable release gives us more room for input, I think...)
@khusmann - Oh my gosh!! Yes. I will update my radio and take a look. This is absolutely wonderful! Oh, and I see the time is also here! Very good.
Update: I am now on 0.8.5 on one of my two radios.
I am updating now and indeed, the firmware description has GPS sharing in it!
Note that GPS info is only available when the device is configured to turn the GPS module on (it's in auto-beacon mode or ID signaling is on).
It'd be nice to have a way to be able to turn the GPS Module on to use GET_POSITION without needing to also enable beaconing or ID signaling. I'm thinking something like setting the beacon interval of 0xFF would never auto-beacon, but keep the GPS module on... @Ylianst What do you think? I'm going to see what Benshikj thinks as well.
I am glad you mentioned that. Indeed if the goal is to replace the built-in beacon with a custom one that adds custom telemetry, etc. Having the GPS enabling without the radio doing it's own beacon would be what we want. I am thinking that sometimes we just need the GPS coordinate when starting up and so, if I have the flexibility to turn off the GPS after getting a position, that would also be great.
All this to say, your 0xFF idea would work great.
@khusmann - Probably something I am doing, but I am sending out command "0002804C03" and getting "0002804C03" back. I am on firmware 0.8.5. Should I be sending a different command? Thanks.
-----> 0002804C03
Response 'BASIC' / 'GET_POSITION'
Position Replay: 0002804C03
@Ylianst hmm, that doesn't look quite right, where are you getting that from? I'm sending 0002004c
Ooh, just got some more info! No need for my 0xFF setting:
You can use REGISTER_NOTIFICATION = 6, POSITION_CHANGED = 13. This way the device will enable GPS and automatically send notifications when the location changes.
Ok, I intended to say, I send out 0002004C and get back 0002004C03. So, maybe the GPS is off or not locked yet.
For REGISTER_NOTIFICATION = 6, POSITION_CHANGED = 13. If you have details on how that works. Your saying that you can get notified when the position changes? That would be amazing!
Oh! yeah, the 03 at the end is the code for "insufficient resources". It does that when there's no gps info to give (because no lock).
Your saying that you can get notified when the position changes?
Yup! I'll add it to benlink soon and it'll make sense!
Ok, @Ylianst I can confirm the position notification works great -- when you REGISTER_NOTIFICATION with POSITION_CHANGED, the GPS on the device will turn on, and automatically send you the current GPS location every second (or every "change" including clock tick, it's not clear which)
I have a rudimentary version of this in benlink; if you construct a RadioController and then radio.enable_event("POSITION_CHANGED") you'll start seeing the position updates streaming in. (The raw bytes for this message is '000200060d', where the last byte 0x0d represent the POSITION_CHANGED type of event)
Here's the full list of events you can monitor:
HT_STATUS_CHANGED = 1
DATA_RXD = 2
NEW_INQUIRY_DATA = 3
RESTORE_FACTORY_SETTINGS = 4
HT_CH_CHANGED = 5
HT_SETTINGS_CHANGED = 6
RINGING_STOPPED = 7
RADIO_STATUS_CHANGED = 8
USER_ACTION = 9
SYSTEM_EVENT = 10
BSS_SETTINGS_CHANGED = 11
DATA_TXD = 12
POSITION_CHANGE = 13
For some reason HT_STATUS_CHANGED includes DATA_RXD, HT_CH_CHANGED, HT_SETTINGS_CHANGED, and maybe some more... perhaps it was originally an option to turn everything on or off, but then the later more options were added for finer grain control.
Also -- note that DATA_TXD is an available notification now as well!
@khusmann - Oh very nice! I really need to get on adding GPS support to HT Commander. It looks like this is really excellent. Also, "DATA_TXD" is a event?!?!? If I understand correctly, that means that I could add in my packet capture all the frames sent by the radio? That would be wonderful. I could see outgoing APRS packets in the capture window.
@khusmann - I tried registering for notifications on DATA_TXD, but I get an error when. Just wanted to check if that is also what you see?