@Giga Yes technically that’s possible, that would make it into a “Super” UART meaning we can take commands from the UART device and forward them to any CAN connected node on the bus, we can also filter out devices by ID to know who replied.
In other words, this can turn any connected UART device into a CAN capable one.
@enzymlefax Thanks for the report, I’m aware of that issue affecting Android devices and I have been working on fixing it for the last couple of days.
Today I finally got it to play nice with Android and I’m waiting on some test results before pushing the update.
The update should make the iLogger discoverable again on Android devices, fix pairing issues, and improves BLE stability.
Hopefully today or tomorrow, I’m working closely with @tinp123 helping me do some final app testings on Android, he has been very helpful. We fixed the discovery issue, improved BLE stability, and currently working on fixing MTU size request to support larger notification sizes, right now it is truncated to 20 bytes, looking to increase it to 185.
If you got only one device at the can-bus this can be easily done, even a bluepill (STM32F103 ~2€) can do this.
The challenge for the iLogger is to have different transmit and receive functions for the internal routine (with his own CAN-ID) and the UART device (having it’s virtual CAN-ID). Also the addressing to the receiver is challanging, since the UART message doesn’t (usually) contain it. So you can not act as a real CAN-device but only communicate with with one CAN-Device bidirectional and with all others unidirectional (only receive).
Right, but it’s very easy to append an ID to a UART message, the host UART device can do it if it’s expecting to operate through a CAN relay. There can be a general protocol agreement where the iLogger extracts the ID from the UART command, and forward the data.
Well, theoretically you can just always use the COMM_FORWARD_CAN command even when accessing over UART, so that the message will get forwarded to the right node no matter which interface you use.
But the usecase will be that ppl want to use the additional UART for e.g. a Flipshit remote or maycrap which certainly don’t do this.
In that case when the devices are kinda firmware fixed ( like the remote receivers you mentioned) we can just forward the commands to all connected vescs on the bus, because thats what we want anyway.
Sorry about the delay, I’m fixing tons of bugs as I’m writing this, I want to consolidate as much of the fixes on this update as possible. Most of them are Android related (Pin bonding and characteristic read/write issues). I have also got to test compatibility with Vesc Fw 5.1, fixing some CAN related issues.
On a side note, I received confirmation that batch 2 is almost done being assembled.
Connect to your iLogger using the Infinity Tool, make sure it is connected to a wifi access point (Green LED is ON), go to settings, “Check For Updates”.
If your iLogger is connected to the internet, you will see a message saying that a new version is available, and it is going to start the firmware update automatically.
Wait until it says update done successfully, this can take a few minutes, please do not interrupt.
Place the firmware update named “update.bin” in the root of your SD card, put the sd card back in while the iLogger is turned off. Before turning it on, press and hold the failsafe button. Turn on the module, then release the button.
iLogger will try to find the update.bin file in the root folder of the SD card, and it will perform the firmware update automatically (The blue LED will blink very fast when it is being flashed).
*Give it a minute or two, iLogger will reboot automatically when the update is done.
I just discovered two more bugs that I’m going to release a fix for today:
First bug is related to “Apply” button sometimes not waiting for the settings data to be saved.
Second bug is related to a memory issue where a data struct randomly gets corrupted at runtime causing the iLogger to go berserk.
If you haven’t yet updated wait for today’s update.
Also after some fiddling (mostly clicking the same buttons over and over) I was able to get it to work but still no gps detection and also not detecting WiFi under the WiFi indicator even though it is and can check for OTA updates.
This is due to a bug on the apply button, I have fixed it and pushing an update soon.
If it’s updating it means it is already connected, sometimes the wifi indicator does not update right away, if you close the settings page and tap open again it should update.
A newer firmware 0.06 is coming up soon that should fix even more things.
Major iLogger FW optimization update 0.07 is here: Re-pairing is necessary, unpair/forget module before connecting again.
Upgraded BLE stack solving some compatibility issues with Android 10 and Samsung devices.
Major memory optimization, firmware now uses around 10x less memory.
Bumped ESP32 frequency to 240Mhz
CAN improvements:
Optimized CAN packets reception task
Changed CAN baud rate to 50k. After many trials, I concluded that 50k baud rate is the most stable. To use CAN port change Vesc CAN baud rate to 50k, if dual change on both.
Second batch update:
I received the second batch of the iLoggers v0.2, completed testing the hardware, and installed the latest firmware on them.
I will start packing and shipping from Monday.
Can I take the card plug into the pc and unblock them to post process them in any other software? Or even export using any other way from the app? The raw csv I mean
meaning we can take commands from the UART device and forward them to any CAN connected node on the bus, we can also filter out devices by ID to know who replied.
