"discover_devices" not detecting "i-CONSOLE" #2
Comments
Your device might have another name... |
|
Otherwise find out the address and hardcode it. |
|
It appears that the iConsole bluetooth-LE models (at least mine) use the Microchip RN4870/71 proprietary protocol to expose the UART over BLE instead of classic bluetooth. As the current script uses bluez and classic bluetooth, I think a few changes are needed to support this. The chip is described here: The serial interface uses the following BLE characteristics: I have not yet checked whether the underlying serial protocol is the same. I might at some point, but in any case I did a lot of googling to figure this out so I hope this helps anyone. Edit: I see newer versions of pybluez do support BLE, through a separate module |
|
Too bad I can't test it, as I don't own such a device, so pull requests are welcome. |
|
What is currently holding me back from trying is not being able to find a library for Python that provides an UART-like abstraction over the Microchip BLE UART protocol. It's not too involved so I might have a go at doing so myself at some point, but it's hard to test if it is correct (a bit of a chicken-egg problem) with the exercise bike being the only such device I have 🙂 |
|
Will be interested to see if you manage to get anything working with the ble. Ive been toying with the android code to also make it work for ble iconsole bike. Can get the code to connect, read default characteristics and enroll for notifications on the custom ones but the bike doesn't go into the 'bluetooth' state so just times out and powers off after a while |
|
Here's an adapted version that (I've only quickly tested) works over BLE by emulating an UART over pygatt: It creates a log file It seems to work. It does some negotiation, the bike goes into bluetooth state (display turns off, buttons no longer respond), and the tool reports some information! |
|
Cheers! I'll take a look. I'm not used to python but it's the negotiation bit that I'm obviously lacking in my java attempt. Thought it'd be as simple as enrolling to the notification characteristic but theres clearly a little more to it |
|
Subscribing to the UART_TX ( |
|
I got around to trying around with this a bit today and it works great. Some observations:
|
|
Thanks again for the useful comments. I've still not managed to get it set up properly. I can now start the proper pairing process going through the various send and receives, however I never get a reply to the Init_A3 send. Don't suppose you have any ideas why - or any more details on what these exchanges are, or how to check them for my device? |
|
My guess for the misc initialization packets is that
Glad to hear you got it so far. It's my experience that packets are ignored if the checksum (the last byte) is not correct. It might also be that they changed the length of the packet for your version. You could skip A3/A4 completely and try what happens. |
|
Thanks. I'll play around with it some more. I have already tried sending A3 then moving onto A4 but I don't get a reply to that either or the Read request |
|
It seems like the A3 causes synchronization to be lost completely, then. If it's really this packet jamming things up, this definitely points at a wrong length issue. A wrong checksum would still make it respond to new packets, I think. Just curious, what is the (version?) response to |
|
Hi, I definitely get a different response to InitA0 send. I am getting F0 B0 00 C8 68 (the same as for the pings). [Sorry took me 2 edits to write that out right - brain fail today!] 2020-11-17 11:45:33.329 2963-3456/org.surfsite.iconsole D/BluetoothLeService: : comm F0 A0 01 01 92 | PING |
Yup. That does look like a slightly different protocol, similar enough, but also different enough to be a challenge. I'm surprised how often 0xC8 (200) comes back in the responses (really in every single one). Also 0x00 appears which doesn't ever appear in the responses from my device. |
|
Hi, I was reading silently since a couple of days now. I have a Asviva rowing machine which also has a iConsole Terminal. But this one uses a Microchip BM70/71 module rather than a RN4870/71. @vmedea python script seems to communicate somehow, but not as supposed. I compared the user's guides of each and they seem to have different command sets. I will go into this deeper the next days. I just want to say thank you for your effort and free information for now, it's very helpful. |
Mine is a crosstrainer "Focus Fitness Fox 5 iPlus". It has the SET_LEVEL 0..31 difficulty setting, which works automatically. Some information I could collect through Linux Going down the BLE rabbit hole: All this seems to reveal is information about the UART / BLE communication chip used, and nothing about the underlying device.
Seems you are right in my case too ! RN was just a guess but the information in that datasheet worked for me. The difference is probably not at the level of the UART chip but what it communicates with. |
|
Hi, well, OK, I was hoping, this might be my problem. When I start your script it goes to line
(I can read "OK" but nothing else) and runs this function repeatingly because got == None doesn't change However the LOG-file is filled with stuff like this
|
|
Well, the good news is that the UART emulation is working. The bad news is that the iConsole specific code gets a longer packet back than expected: The PING packet gets you back the expected The following would work to get past: Though it's hard to say which other packets will differ in responses. |
|
Hi, so I did a little more digging, I ripped your script ;) so that it simply sends hex-strings and prints out the response strings, the response of my machine is quite boring by now: to any of your commands INIT_A0 ... READ except for PONG and INIT_A4 the response is
as soon as I try other hex strings (e.g. modifying the PING command by changing random values +-1) I did not get a response string (as with PONG and INIT_A4). Thus I assume it accepts these strings as commands in some way. Where did this strings come from? I did not find any references in the user guides?! P.S. the response does not change if I pull the rower during data transfer |
Yea, the problem is that this protocol, no version of it, is documented anywhere at least that I know. My luck was that @haraldh's worked for me as-is. Trying strings will only get you so far if the protocol differs enough. At some point the only way to get something working is to intercept the traffic between the original app and the rower somehow, as that's bound to be valid. Maybe there is some way to intercept it at the android system level, or a way to emulate the app. Another option would be to reverse engineer the app and figure out the calls to bluetooth API. Alternatively there is probably some way to sniff BLE traffic drectly from the air (it's not encrypted in/ this case), but it might require special equipment. |
|
I went through the documents for BM70/71 and RN4870/71 and I think I finally understood. These provide the GATT server and UART interface for the underlying fitness console (aka iConsole). The BT Characteristics and GAP/GATT Services are provided by the BM/RN but the command strings communicate with the console which is not documented. Just for the fun of it I ordered the hardware as described here https://www.polidea.com/blog/bluetooth-low-energy-sniffing-guide/ and see what this brings... |
|
I turned on bluetooth logging in the android developer settings back in the days and ran the original iconsole app. https://www.bluetooth.com/blog/debugging-bluetooth-with-an-android-app/ |
|
wireshark is your friend to look into the contents of the network packets. |
Yes, exactly. The UART can best be considered a dumb pipe, it can be the Nordic UART module (over classic bluetooth), Microchip UART module (over BLE), or even a serial cable. These hold no mysteries. But the application-specific wire protocol over it is undocumented, and clearly has a few variants. Good luck! |
|
I also opened up the discussion forums |
|
@vmedea @haraldh do you have any code we could look at? We are a research team working with brain injury patients and we are working on a small gamified prototype to increase their workout motivation. We bough the iConsole powered bike Head S330, but we are unable to connect or read data from it. I read through your conversation but I am unsure if you have succeeded. Thank you kindly. |
|
@tomitrescak I've uploaded my current code. It works for my BLE iConsole device, hope it works for the one you are using, but there seem to be different protocols so YMMV. |
|
@vmedea thank you! It gives me a lot to go on ... now I have to make it work on Windows in UWP ;) |
|
@vmedea & @haraldh thank you for the work you are doing on this! I tried connecting today (I have a spinning bike with manual resistance control) and get a timeout in the INIT_A0 step. Log reads as: Connected to device Any thoughts? |
Hi, I am new to bluetooth (especially BLE) but want to gather data from my new Cardiostrong Ergometer BX70i. Works perfect with the IOS App iConsole+ ... Other IOS BT sniffer work also.
My goal is to connect with a raspberry 3 and log performance data into a csv file like (timestamp;power level;rpm;heartrate,etc ...) approx. every 5 or 10 secs in order to track the exercise.
I want to use your script to connect and communicate with the iConsole (not interested in the ANT part)
Other bluetooth devices (e.g. my Samsung Galaxy phone) are detected by your script.
My Bose Speaker in range is not shown, so it seem to be low energy devices are ignored.
Raspberry 3 Stretch version 9 (internal Bluetooth), HCI 4.1 Rev 0X145, bluetoothctl, bluez 5.48
Any glue what could be the problem here ?? Thanks, Gerhard
The text was updated successfully, but these errors were encountered: