armel
Change Transverter bands
I got this running on a IC-905 using USB/Proxy method no problem. The 905 has some extra meters or changed meters (like voltage that changes for the microwave bands) but the common stuff seems to work the same OK.
A neat feature would be to change transverter bands with menu and/or touch and automatically adjust the offset per band, and send the calculated IF to the radio for each band. Some could be 144 IF, others 28 for example with resolution to the Hz level to account for crystal/TCXO errors between transverter LOs.
Along with such capability GPIO is used per band to switch antennas and transverters.
Last request is to add direct USB connection to the radio skipping the WiFI/Proxy need. M5Stack has a USB host module that could talk to the radio direct over USB serial. I have this working today on a Teensy 4. There are esp32 USB host examples but I have yet to find one for serial. Many for keyboards, mice, PS3 controllers.
Pictures attached are from my IC-905 on 23cm band, though a Windows 11 proxy, no python script changes required. Specifed COMx in place of the /dev/tty/xxx device name in the config files on the SD card.
Hi Mike,
Thanks for your very interesting feedback. IC-705 and IC-905 share many CI-V commands. This explains why my developments work pretty well with the IC-905.
But, I don't feel able developing new things to improve the IC-905's support. It's too complicated, without having this transceiver in front of me. I don't have the money to acquire an IC-905. It's just a dream for me. But if Icom wants to offer me one, I'll take it and, of course, I could work to improve IC-905's support.
And about the direct USB connection, you're right, that would be great. But if you only knew how much time (nights...) I've spent trying to do it, without succeeding...
Thanks again for your feedback. I really appreciate it.
73'
Armel F4HWN.
The IC-905 has 2 serial ports on the USB C. CAT on ch 'A' and ch 'B' is configurable, I have it set for the GPS NMEA data to sync a PC clock with.
The 905 is connected to the M5 USB Host shield and the PC (Arduino IDE) is on the main USB. I just got the GPS data to print out. It is address 0x0A. Now to get address 0x41. The hub_demo correctly sees the 2 serial and 1 audio channels. Just have to figure out how to specify the one I want now. Using the CDC acm_terminal and hub_demo example programs.
Happy to post the code assuming I get this figured out. I really do not understand how this all works but making some headway.
Here is the data flowing from the 905 ch B.
rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0030,len:1344 load:0x40078000,len:13964 load:0x40080400,len:3600 entry 0x400805f0 Start ACM Init Addr:0A NC:01 Endpoint descriptor: Length: 07 Type: 05 Address: 83 Attributes: 03 MaxPktSize: 0010 Poll Intrv: 10 Endpoint descriptor: Length: 07 Type: 05 Address: 86 Attributes: 03 MaxPktSize: 0010 Poll Intrv: 10 Endpoint descriptor: Length: 07 Type: 05 Address: 01 Attributes: 02 MaxPktSize: 0040 Poll Intrv: 00 Endpoint descriptor: Length: 07 Type: 05 Address: 82 Attributes: 02 MaxPktSize: 0040 Poll Intrv: 00 Endpoint descriptor: Length: 07 Type: 05 Address: 04 Attributes: 02 MaxPktSize: 0040 Poll Intrv: 00 Endpoint descriptor: Length: 07 Type: 05 Address: 85 Attributes: 02 MaxPktSize: 0040 Poll Intrv: 00 Conf:01 ACM configured $GPGGA,134039.00,4746.9255,N,12201.9856,W,2,12,1.0,155.5,M,-18.2,M,,59 $GNGLL,4746.9255,N,12201.9856,W,134039.00,A,D64 $GNGSA,A,3,19,17,22,06,11,12,24,03,,,,,1.6,1.0,1.326 $GNGSA,A,3,86,88,76,87,,,,,,,,,1.6,1.0,1.328 $GPGSV,3,1,12,01,38,218,,03,09,032,29,06,60,093,45,11,45,169,357B $GPGSV,3,2,12,12,54,300,18,17,21,064,36,19,46,060,41,22,18,112,3171 $GPGSV,3,3,12,24,44,223,27,25,22,299,,32,07,311,00,48,35,184,3977 $GLGSV,3,1,09,69,04,315,,70,07,013,00,76,12,139,23,77,58,139,226E
According to the CoreS3 USB host library comments the ability to handle multiple serial ports on the common USB host connection is on a wish list. That is needed for passing through the GPS data, a nice to have, but not a deal breaker.
I now have a fairly complete working Teensy4.1 version with band decoding outputs and PTT break for multi band use (aka remote controller). Can be headless or use optional 7" or 4.3" touchscreen display and encoders. Can be put into transverter control mode where all control is from the remote controller radio bands may be used with different settings for each transverter or direct. It is working IC-905 and IC-705 via USB.
I want to get it working on BT for the 705 (or 905 with USB dongle). I borrowed a 705 for a time to test with. For a full solution some buffered IO is needed for antenna and amplifier relays, possibly 28VDC, and transverter control. This all has to be put into a box.
For a simplest case just need a small number of buffered IO pins and minimal display with buttons, encoder or touch to see the transverter frequency, calibration offsets, choose the band, and monitor status. Ideally this is on a prepackaged hardware that does not cost too much. And it should have WiFi for future use and BT. The Teensy lacks BT/WiFi so extra work and cost required.
One option is the OpenSprinker 3.0 DC model. 8 outputs, expandable, OLED screen, 3 buttons, WiFi, BT. i2c and SPI expansion headers inside and outside. Arduino too.
I am coming back around to the M5Stack. My old M5 Core does not have enough flash. I bought an M5Core3SE with USB 1.2 module. The BT BLE may be an issue, but I am investigating this more, I found single and multiple SPP examples, not sure if they really work on the Core3 yet. Hoping for the best, I ordered some 4IN/8Out, Proto peg board, HMI w/Encoder, PLC Proto baseV11, and a DIN base to go with my USB module v1.2 to add a second USB for host port duty. The idea is that a stacked set of modules can house all that is needed along with the decent touch display and plenty of buffered IO, no hardware build required, just cabling. Power can be from 12-24V or USB. I am also still looking into WiFi control.
The additions feature-wise are configurable buffered IO, master control mode for multiband transverter support, PTT breakout (PTT per band).
Will update my progress, code is on my GitHub as I progress so you are welcome to any of it.
The 905 and 705 are nearly the same from your display's perspective for your current feature set. The main difference so far is frequency in the CI-V messages will be 6 bytes when on 10GHz or higher, and 5.7GHz band requires a 64bit variable, most solutions use 32bit today. Some other things are preamp and attn are not available on 24GHz and above. It also has a temp meter the same size and style as the voltmeter (Vd). Vd changes scale with each band type. I am happy to test changes if you like.
Hello,
Hmmm, about M5Stack CoreS3 (or CoreS3 SE), I couldn't connect it by Bluetooth with my IC-705. As you said, CoreS3 use a BLE chip. It seems that IC-705 embed a Bluetooth chip that support BLE profile too (HFP, HSP, SPP and LE). But I was not able to understand how to use it. And there is no Icom documentation.
Regards,
Armel.
In the example file BLE5_extended_scan.ino they start with an event type ESP_BLE_GAP_SET_EXT_ADV_PROP_LEGACY
if(report.event_type & ESP_BLE_GAP_SET_EXT_ADV_PROP_LEGACY){
// here we can receive regular advertising data from BLE4.x devices
Serial.println("BLE4.2");
I am trying to get any BT example to run, which they do, but I have yet to connect to it from or to anything. Just getting started though, I am new to BT code - I just learned that BLE is not compatible with Classic BT :-). The Core2 uses a 4.2 dual mode controller.
From the Core2's ESP32-D0WDQ6-V3 CPU datasheet:
- Compliant with Bluetooth v4.2 BR/EDR and Bluetooth LE specifications
- Multi-connections in Classic Bluetooth and Bluetooth LE
- Bluetooth 4.2 BR/EDR and Bluetooth LE dual mode controller
The S3 datasheet says it has BT5, LE and mesh. BT5 is supposed to be backward compatible with classic BT devices. With the 705 saying LE, and BT5 being backward compatible, there should be 2 ways to connect. I am still looking for just 1 way that works....
In my reading it appears the ESP-IDF is the limitation, only supporting BLE for now. But that conflicts with this S3 documentation:
https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-guides/bluetooth.html#profiles
and
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/bluetooth/esp_bt_defs.html#
https://www.espressif.com/sites/default/files/documentation/esp32-s3-wroom-1_wroom-1u_datasheet_en.pdf
which says ESP32-S3 includes a Bluetooth Low Energy subsystem that integrates a hardware link layer controller, and RF/modem block and a feature-rich software protocol stack. It supports the core features of Bluetooth 5 and Bluetooth mesh
I now think the documentation examples for the S3 are conflicted, perhaps leftover form previous versions of ESP. The hardware docs mention only "Bluetooth LE supporting core features of BT5". I now take that to mean they have BT LE at BT5 generation specs, but not dual mode.
I cannot get the 705 to hold a connection with my Win11 on NUC12 machine. Connects and drops, most of the time if fails to connect.
Going down the LE route, if I run the BLE_scan.ino example in Arduino samples for CoreS3 I do see the 705 BT device listed:
[226272][D][BLEAdvertisedDevice.cpp:472] setRSSI(): - setRSSI(): rssi: -61
[226275][D][BLEAdvertisedDevice.cpp:292] parseAdvertisement(): Type: 0x01 (ESP_BLE_AD_TYPE_FLAG), length: 1, data: 02
[226285][D][BLEAdvertisedDevice.cpp:292] parseAdvertisement(): Type: 0x07 (ESP_BLE_AD_TYPE_128SRV_CMPL), length: 16, data: 0342f170b22e041b08d4c21e0180cf14
[226299][D][BLEAdvertisedDevice.cpp:500] setServiceUUID(): - addServiceUUID(): serviceUUID: 14cf8001-1ec2-d408-1b04-2eb270f14203
[226310][D][BLEAdvertisedDevice.cpp:292] parseAdvertisement(): Type: 0x19 (ESP_BLE_AD_TYPE_APPEARANCE), length: 2, data: 0000
[226321][D][BLEAdvertisedDevice.cpp:437] setAppearance(): - appearance: 0
[226328][D][BLEAdvertisedDevice.cpp:292] parseAdvertisement(): Type: 0xff (ESP_BLE_AD_MANUFACTURER_SPECIFIC_TYPE), length: 3, data: 750400
[226340][D][BLEAdvertisedDevice.cpp:449] setManufacturerData(): - manufacturer data: 750400
[226348][D][BLEAdvertisedDevice.cpp:292] parseAdvertisement(): Type: 0x09 (ESP_BLE_AD_TYPE_NAME_CMPL), length: 15, data: 49434f4d2042542849432d37303529
[226361][D][BLEAdvertisedDevice.cpp:461] setName(): - setName(): name: ICOM BT(IC-705)
Advertised Device: Name: ICOM BT(IC-705), Address: 30:31:7d:33:bb:7f, appearance: 0, manufacturer data: 750400, serviceUUID: 14cf8001-1ec2-d408-1b04-2eb270f14203, rssi: -61
[226369][D][BLEScan.cpp:105] handleGAPEvent(): Ignoring 40:16:3b:db:0f:67, already seen it.
Eventually you get a list of devices already in their scan list and it includes my IC-705 address
[404795][D][BLEScan.cpp:105] handleGAPEvent(): Ignoring 30:31:7d:33:bb:7f, already seen it.
The scan info seems to understand the 705 BT parameters, I think that means it is LE compatible at the lowest level. Now to figure out if it is usable for us.
Just a FYI, using NimBLE BLE library, no problem discovering the device. Talking to it is another matter. I have an old 4MB flash M5Stack Core connecting to the 705 using the Classic BT Serial, it is still sold so that remains a backup plan. But not ready to give up on BLE yet. The LE on the 705 BT info keeps me hopeful.
I NimBLEScan: New advertiser: 30:31:7d:33:bb:7f
I NimBLEScan: Updated advertiser: 30:31:7d:33:bb:7f
Advertised Device found: Name: ICOM BT(IC-705), Address: 30:31:7d:33:bb:7f, appearance: 0, manufacturer data: 750400, serviceUUID: 14cf8001-1ec2-d408-1b04-2eb270f14203
Hi,
Yes, I know, I've spent a lot of time trying to connect to BLE. But from what I understand, BLE uses notions of service UIDs. Instead of sending a sequence of commands to access this or that transceiver parameter (as I do with serial Bluetooth), we access a service UID that responds to us. I think the 705 has a sort of dictionary of service UIDs for each parameter. At least, that's what I think. But nothing is documented about this. I've seen a few examples with weather sensors. There was a service UID for temperature, a service UID for pressure and a service UID for humidity. I assume it's the same on the 705, but I don't know.
Armel.
@armel Here is a project that uses BLE to connect to the IC-705. I use it for satellite doppler tracking on a 705 with an iPhone. It may give you some insight on how to start. The BLE implementation still uses CI-V formatted commands with just enough BLE wrapper to make it work. https://github.com/brills/SatHunter
Most of the relevant code is in this file: https://github.com/brills/SatHunter/blob/main/SatHunter/Rig.swift
Thanks for the pointer to SatHunter. This is the 2nd Swift coded app I have ever looked at, crosses my eyes a bit as I am a traditional C guy, never got into OO. I know zip about BLE but I plugged the UUID into the BLE client example to try and connect.
In your SatHunter code the service and characteristic UUIDs are the same.
Interesting the UUID in your code is 1 number different then the UUID in the logs above 14CF8001-1EC2-D408-1B04-2EB270F14203 vs your code having 14CF8002-1EC2-D408-1B04-2EB270F14203
The BLE client app finds the radio, tries to connect, creating a client, and trying to connect to the server. It fails to find the characteristic UUID:
Log below on a M5Stack CoreS3SE.
BLE Advertised Device found: Name: , Address: 04:8a:54:16:19:34, manufacturer data: 06000109212a7f4d3c4a89304b374d444c32, rssi: -78
BLE Advertised Device found: Name: ICOM BT(IC-705), Address: 30:31:7d:33:bb:7f, appearance: 0, manufacturer data: 750400, serviceUUID: 14cf8001-1ec2-d408-1b04-2eb270f14203, rssi: -47
Forming a connection to 30:31:7d:33:bb:7f
- Created client
- Connected to server
- Found our service
Failed to find our characteristic UUID: 14cf8001-1ec2-d408-1b04-2eb270f14203
We have failed to connect to the server; there is nothin more we will do.
onDisconnect
Tried sub in the 14cf8002 UUID for the characteristic UUID, still failed. BLE UART example fails also.
Running the NimBLE version of the Arduino BLE_client example it circled around and failed as above for quite a while. I changed the characteristic UUID to use the 14cf8002 string and it magically started connecting every pass.
BLE Advertised Device found: Name: ICOM BT(IC-705), Address: 30:31:7d:33:bb:7f, appearance: 0, manufacturer data: 750400, serviceUUID: 14cf8001-1ec2-d408-1b04-2eb270f14203
Forming a connection to 30:31:7d:33:bb:7f
- Created client
- Connected to server
- Found our service
- Found our characteristic
We are now connected to the BLE Server.
Setting new characteristic value to "Time since boot: 171"
Setting new characteristic value to "Time since boot: 172"
Setting new characteristic value to "Time since boot: 173"
Setting new characteristic value to "Time since boot: 174"
Progress!
FYI, the particular NimBLE example I am running now is found in the NimBLE-Arduino Refactored original examples
The refactored UART example does not compile, looking into why. The non BLE version complies but both of these are server role so just sits at "waiting for client to connect prompt" so need to flip the roles.
I found a client example modified for Nordic UART https://github.com/ThingEngineer/ESP32_BLE_client_uart It crashed after "- Remote BLE RX characteristic reference established" is printed. Fixed it by adding return true; at the end of the function.
Now it cycles between "Notifications turned on" and the same for off every 5 seconds. No pairing to the radio, no BT connected status symbol on the radio screen. Now to figure out how to get the CI-V portion connected and transferring data. Will take another look at SatHunter for clues.
I got it working. progress. I used the ThingEngineer source above. Looking at the Sat Hunter code, I added Send UUID, Send Name, and Send Token commands. Plus some other minor additions to ensure serial data is exchanged.
BLE Advertised Device found - Name: ICOM BT(IC-705), Address: 30:31:7d:33:bb:7f, appearance: 0, manufacturer data: 750400, serviceUUID: 14cf8001-1ec2-d408-1b04-2eb270f14203, rssi: -58
Found a device with the desired ServiceUUID!
Establishing a connection to device address: 30:31:7d:33:bb:7f
- Created client
- Connected to server
- Found our service - Remote BLE TX characteristic reference established
The characteristic value is currently:
- Remote BLE RX characteristic reference established
The characteristic value was:
We are now connected to the BLE Server.
Notify callback for TX characteristic received. Data:
FE F1 0 62 FD
Notify callback for TX characteristic received. Data:
FE F1 0 63 1 FD
Notify callback for TX characteristic received. Data:
FE F1 0 64 FD
Notify callback for TX characteristic received. Data:
FE FE 0 A4 0 0 0 80 95 0 FD
Notify callback for TX characteristic received. Data:
FE FE 0 A4 0 0 0 70 95 0 FD
Notify callback for TX characteristic received. Data:
FE FE 0 A4 0 0 0 80 95 0 FD
Notify callback for TX characteristic received. Data:
FE FE 0 A4 0 0 0 70 95 0 FD
The first 3 replies are for UUID, Name and Token I sent. The last 4 are VFO frequency changes.
I have BT SerialPort Function "CI-V Echo Off."
The name I sent shows in the Pairing/Connect screen.
For the UUID I used an Android value I found online, can be anything I think. The radio stores that value to auto connect later. In my test coded I made simple arrays of hex values. Will do something more elegant later.
To connect, I open the Pairing Reception menu then reset the ESP-S3 (M5Stack core S3SE). Sometimes I missed the reply for the token and no connection is made. a small delay seems to have solved that.
I added polling for PTT and frequency, suppressed some debug text. Created a new repo for it on my GitHub. Renamed the file as well.
https://github.com/K7MDL2/IC-705-BLE-Serial-Example
@K7MDL2 Thanks for sharing all of this as you worked through it. I've spend a few evenings this week trying to get an M5Dial which uses the ESP32-S3 working BLE to the 705 and gave up. I was also using CircuitPython which might have some bugs in the S3 BLE implementation as it is a little newer. Your code will give me something to sanity check against.
I eventually just ordered a Core2 V1.1 that will be here in the next hour or two and planned to just revert to BT Classic. I also need to control and IC-7000 at the same time and I have a cheap BT Classic to CI-V adapter for it, so this will let me do everything wirelessly where I was going to have to make a hardware CI-V connection on the S3 board. (I use an IC-705 on receive and an IC-7000 on transmit for my portable satellite station)
Also to clarify, SatHunter isn't my project. My initial plan was to modify it to fit my needs but I also go cross-eyed trying to read Swift :)
Nice job @K7MDL2 ! I'll take a look when I have time, but it's a great step forward 👍🏼
In my simple band decoders on the Teensy and very soon M5Stack, I can read input IO, or use UI to change to a new band, including transverter bands.
I have a 4-in and 8-out MOSFET driver module to buffer that output and read up to 4 lines from a switch or radio decoder output (K3, Yaesu). The outputs switch to ground at up to 24VDC@1A each to switch antennas, transverters and amps. I also break out PTT per band. Ideally this would be read from a config file on the SD card.
I monitor PTT via CI-V and can issue PTT via USB, not sure how that works with BT.
These would be great features for your version. Now that BLE is figured out, my CoreS3 can be used. My old Core only has 4MG flash so cannot run your app. My stripped down version has a place and is needed for now to do the band decoder functions, but no denying the utility of the UI you have.
On the Teensy version it is a master controller that sends down all key radio settings per band, real or Xvtr as needed since the radio has no idea what it is being used for. That means I needs to display them, and try to detect any changes from the radio side where reasonable and store them per band.
- Mike K7MDL
An update. In the enhanced program example on my repo linked above, I believe I finally reached a robust self-healing BLE connection solution to the 705. UI is minimal for now but shows frequency, band and PTT status, seems pretty quick. The Readme has many details on connection states and some pitfalls I ran into. When I thought I had a good solution to auto-recovery, I always found a problem including malloc or pointer crashes, or when using the onDisconnect callback, it seems too slow. Seems like that is all fixed now. I can walk out of range, power off radio, disconnect it via the menu, all seems to reconnect on its own now without any crashes or mallocs I can see.
Next I will work on some improved UI but mostly I need to add in band decoder outputs and PTT breakout for the amps, transverters and antenna relays. I and several others are waiting for this for 705 and IC 905 (via USB) microwave setups. That means I will be working on the M5stack USB version also. I have IO and a USB host module to get PC passthrough for a USB connected PC.
I have to return the IC-705 I am borrowing soon along with a working decoder/PTT breakout.
I made a minor but significant discovery today about the 4 CI-V commands and replies to pair and reconnect with the radio. Also what happens when you are not paired and try to connect when the radio is not in pairing mode, or when you the radio side does something like disconnect the device. Details are updated at my readme https://github.com/K7MDL2/IC-705-BLE-Serial-Example/blob/main/README.md
- The 0x61 is a real message with no replay - likely a radio bug. It is a 32byte UUID, so 41 total. If it is too short the reply for the 0x62 Name message goes missing. This cause great confusion. I proved the UUID matters. If you change only 1 byte in the UUID, you cannot reconnect and when you pair the radio lists the device name twice. The address is assigned the next sequentially higher. The BT address field on the radio is a 6byte BT Classic address with colons, but for BLE it is filled with 0s and you get auto assigned a number starting with 1.
- The Name field must be exactly 16 bytes for 21 message total. Pad the unused bytes with spaces or something. I was 1 byte shorter when I change the name for testing and everything broke.
- In Scan_BLE_Servers() use the pBLEScan->clearResults(); to delete results from BLEScan buffer to release memory. Malloc errors and crashes happen easily with this process of near endless repeating scans.
- I am guessing that when things are not just right, and your program is hammering the radio for a connection that is not working, the radio stops or severely slows down advertisements. During this time I toggle the radio BT OFF and ON then hit pairing reception and it gets me an advertisement quick.
- I enabled Warn and Error debug level for the compiler. It shows the underlying ESP BT library events. Plenty of "unknown error" messages. It is also the way to see disconnect events.
- When the radio rejects your attempt to pair or reconnect, it does this by disconnecting. You do not see this easily watching serial println() messages. If you try to use isConnect() the pointer you are likely using is NULL between server connections. I initially tried using a callback for onDisconnect() and onConnect(). Seemed like the disconnect events were late or missing at times. so were not helpful prevent the use of transient pointers. I rarely, if ever, saw a connect callback event. I left them in the code, just have to uncomment the callback setup line in connectToServer().
This is long winded I know. I spent many hours learning these things the hard way and wanted to document it for you and me. These seemingly small issues cost me many hours of troubleshooting. I think there are some radio bugs we have to work around as well. I will send a note to Icom. There is probably very little BLE usage to until now given the lack of code or documentation out there.
I will probably freeze the example file and then extend a copy of it for better UI and the actual band decoder IO interface using the M5Stack 4in/8out module, and add host USB using their USB V1.2 module. That is for a USB radio connection. The main USB port will get pass-through CI-V to an optional PC for loggers and digital mode programs like WSJT-X. If do not thin the ESP library supports dual or triple serial ports over USB yet. If it did, I could pass through the GPS NMEA data for PC clock sync. I am using a Teensy 4 for this purpose today.