…because, why not?
About a year ago, I bought a Quansheng UV-B5 radio. The fact that the firmware was “open” allowed a host of different features and modifications made it kind of a cool toy for not a lot of money.
One of the interesting things was the fact that firmware was loaded using chrome as the interface. You still needed the driver on the computer, but chrome handled all of the USB communication and control.
I got to thinking about that, and had the crazy idea that I could communicate with my HF radio, using the same method, and even build a lightweight logging program using only the browser.
I can do OK on a lot of different coding projects, and I had some minor success, but using HTML, I could not figure out how to handle ICOM’s CI – V protocol and translating the data between hex and something that could be read and displayed on a webpage. I quickly gave up on that for the time being. I’ve obviously tackled this before, when using Arduino… but I’m not very proficient with HTML (which is why I use wordpress).
Fast-forward to three days ago, and I had a wild idea that maybe I could use AI to auto generate the code based on my specifications. I’m not a huge fan of things like this when it comes to professional work, but for goofing off, I figured it was worth a shot.
I started out with ChatGPT and had it write a simple script to capture the radio’s frequency. To my surprise, it worked the first time. Well, mostly. The bytes that were captured were displayed in an odd manner, and I realized that it was not reversing the individual bytes when converting hex to decimal for the frequency. Another prompt into ChatGPT, and it admitted that it’s screwed up and corrected it.
I proceeded to try some additional functionality – like setting a mode, and that didn’t work. I have experience with the CI-V protocol, so I figured there was an issue with how GPT was interpreting the protocol…. So I opened the code in notepad and went digging.
When I dug into the actual code, I found that ChatGPT interpreted the CI-V protocol to mean that it ALWAYS required a “payload” data byte or bytes. This is not the case for simple commands – the radio gets only FEFE (target) (controller) (command) (closing). The GPT code was insisting on sending a hex 0x00 for the non-existent payload. When I manually removed this byte, it worked.
I shelved the project for a couple days, because I assumed that it would take a lot of hand jamming code. I chatted with KC0HBM about the project, because it WAS pretty exciting. He asked one great question… “Have you only used GPT, or have you tried any other platforms?”. Well… no. I hadn’t considered that other platforms might return different results. On a whim, I tried Gemini, since I had it on my phone. What a difference!
The initial interface was very similar, but a bit more user friendly. More importantly, when I prompted it to add functionality, like mode changes, the functions worked! They did have some issues, like setting it to AM made the radio go to RTTY, and selecting RTTY made it go to CW. I manually corrected the list of modes vs. hex bytes, and added “DV” for capable radios (IC-705). I encountered a similar issue when I added DVR capability – Gemini kept using “0x1A” “0x01” to initiate DVR playback – the proper code is “0x28” “0x00”. So there is SOME work that has to be done by hand.
I’m still working on the “auto-mode” read on startup, but the frequency portion is working!
here’s a more compact version with some updates:
–UPDATE–
I did a lot of tinkering, and made Gemini help me troubleshoot the “poll frequency and mode on startup” functionality. It came down to a combination of race conditions, essentially.
I’ve tried adding functions to collapse the different sections, but it keeps breaking the radio functionality. I think the next task might be a branch for yeas or Kenwood, but I can’t test those. I’m going to remove the filter function, since it’s kind of an oddball feature that I won’t be using often from the computer.