Adafruit implementation
bsculley opened this issue · comments
Hi Collin,
I am trying to implement the Adafruit module on GEVCU 6.2. I have the module connected and configured in GEVCU, but I'm not able to see a Bluetooth device.
5147 - INFO: - add device: AdaFruit BLE (id: 0x1041, 0x20074EE0)
Do I need to do anything besides connecting it and enabling the device?
Thanks,
Bob
Here's the GEVCU log starting from an 'a' reset. At the end, the DATATYPE=2 error repeats forever.
I tried to run some of the samples included with the library, but got no response at all. Not even the "Adafruit Bluefruit AT Command Example" serial output.
I also tried starting the Bluetooth in verbose mode, but it crashes with a serial port error.
ADABLUE reset
209847 - DEBUG: New checksum: BF
210723 - DEBUG: Set new BLE state: 1
210725 - DEBUG: Factory Resetting BLE
211124 - DEBUG: New checksum: BF
211843 - DEBUG: Set new BLE state: 2
211845 - DEBUG: Sending power level cmd
211854 - DEBUG: Cmd completed as true in state 2
211856 - DEBUG: Set new BLE state: 3
211883 - DEBUG: Sending device name cmd
211957 - DEBUG: Cmd completed as true in state 3
211958 - DEBUG: Set new BLE state: 4
211963 - DEBUG: Sending add service cmd
211972 - DEBUG: Got a new line: 1
211973 - DEBUG: Cmd completed as true in state 4
211975 - DEBUG: Set new BLE state: 5
212003 - DEBUG: Sending characteristic definition
212404 - DEBUG: New checksum: BF
213203 - DEBUG: Sending characteristic definition
213224 - DEBUG: Got a new line: Option Error: UON=TimeRunning
213225 - DEBUG: Cmd completed as false in state 5
213227 - DEBUG: Error setting characteristics!
213243 - DEBUG: Sending characteristic definition
213264 - DEBUG: Got a new line: Option Error: DATATYPE=2
213265 - DEBUG: Cmd completed as false in state 5
213267 - DEBUG: Error setting characteristics!
213283 - DEBUG: Sending characteristic definition
213304 - DEBUG: Got a new line: Option Error: DATATYPE=2
213305 - DEBUG: Cmd completed as false in state 5
213307 - DEBUG: Error setting characteristics!
213323 - DEBUG: Sending characteristic definition
213345 - DEBUG: Got a new line: Option Error: DATATYPE=2
I added a display of the characteristic being sent:
8832 - DEBUG: Sending characteristic definition: TimeRunning
8853 - DEBUG: Got a new line: Option Error: DATATYPE=2
8855 - DEBUG: Cmd completed as false in state 5
8858 - DEBUG: Error setting characteristics!
I also got this sequence, but not consistently:
7531 - DEBUG: Set new BLE state: 5
7559 - DEBUG: Sending characteristic definition: TimeRunning
7761 - DEBUG: New checksum: BF
8759 - DEBUG: Sending characteristic definition: TimeRunning
8783 - DEBUG: Got a new line: Option Error: URESENTATION=08-0AT+GATTADDCHAR=UUID=12545
8784 - DEBUG: Cmd completed as false in state 5
8786 - DEBUG: Error setting characteristics!
Hmmm.. It seems to work for a little bit then fail and get stuck. And, it seems to be corrupting the lines a little bit. For instance, it should be PRESENTATION= not URESTENTATION=, things like that. It seems like U's are getting inserted in there randomly. Maybe the SPI link is going too quickly? It's also possible that they updated the API in the meantime. The code in GEVCU was written in 2016 apparently and recently Adafruit has been updating the firmware again. Have you updated the firmware on your BLE module recently? I'll try to dig up an Adafruit BLE module on my end and see if I can get it to work.
I have not updated the firmware on the BLE module. It appears to be an OTA update, but the device is not providing any Bluetooth connection. I'm getting groups of three flashes on the red LED. Should it be instantiating a Bluetooth connection?
Also, I got the examples to run. The ble.info() call hangs. Here is the output from the atcommand example:
Adafruit Bluefruit AT Command Example
-------------------------------------
Initialising the Bluefruit LE module: OK!
Performing a factory reset:
Requesting Bluefruit info:
Also, got a new message from GEVCU:
7785 - DEBUG: New checksum: BF
8784 - DEBUG: Sending characteristic definition: TimeRunning
8806 - DEBUG: Got a new line: Option Error: UON=TimeRunning
8807 - DEBUG: Cmd completed as false in state 5
8809 - DEBUG: Error setting characteristics!
This only happens on the first attempt to send the characteristic.
Further to this issue, I have managed to connect to the BLE device using the Adafruit android app. I see the device being advertised as GEVCU 6.2 ECU, but the firmware update failed with error DFU DEVICE DISCONNECTED. Is there something I need to do on GEVCU for this to work?
I have asked about it on the Adafruit forum. Maybe I'll get an answer.
Can you confirm a version of the firmware that works with GEVCU? The module I have is 0.6.5.
I bought a new Bluetooth module and am getting the same results as before. Device software is revision 0.6.5. Should I upgrade it? I really need to get this working.
36879 - DEBUG: Cmd completed as true in state 4
36880 - DEBUG: Set new BLE state: 5
36884 - DEBUG: Sending characteristic definition: TimeRunning
36906 - DEBUG: Got a new line: Option Error: DATATYPE=2
36907 - DEBUG: Cmd completed as false in state 5
36909 - DEBUG: Error setting characteristics!
36924 - DEBUG: Sending characteristic definition: TimeRunning
37045 - DEBUG: New checksum: BF
38084 - DEBUG: Sending characteristic definition: TimeRunning
38106 - DEBUG: Got a new line: Option Error: UON=TimeRunning
38107 - DEBUG: Cmd completed as false in state 5
38109 - DEBUG: Error setting characteristics!
38124 - DEBUG: Sending characteristic definition: TimeRunning
38145 - DEBUG: Got a new line: Option Error: DATATYPE=2
38147 - DEBUG: Cmd completed as false in state 5
38149 - DEBUG: Error setting characteristics!
I finally got around to looking into this more thoroughly. I first tried with a unit of unknown firmware version (forgot to check) it did work. Then I tried the Adafruit app and it asked if I wanted to update to 0.8.0. I said yes. It worked afterward too. Here's a snippet of it starting up:
3645 - DEBUG: Set new BLE state: 1
3645 - DEBUG: Factory Resetting BLE
.4755 - DEBUG: Set new BLE state: 2
4755 - DEBUG: Sending power level cmd
4759 - DEBUG: Cmd completed as true in state 2
4760 - DEBUG: Set new BLE state: 3
4765 - DEBUG: Sending device name cmd
4770 - DEBUG: Cmd completed as true in state 3
4770 - DEBUG: Set new BLE state: 4
4775 - DEBUG: Sending add service cmd
4780 - DEBUG: Got a new line: 1
4780 - DEBUG: Cmd completed as true in state 4
4780 - DEBUG: Set new BLE state: 5
4785 - DEBUG: Sending characteristic definition
4799 - DEBUG: Got a new line: 1
4799 - DEBUG: Cmd completed as true in state 5
4805 - DEBUG: Sending characteristic definition
4820 - DEBUG: Got a new line: 2
4820 - DEBUG: Cmd completed as true in state 5
4825 - DEBUG: Sending characteristic definition
4845 - DEBUG: Got a new line: 3
4845 - DEBUG: Cmd completed as true in state 5
4845 - DEBUG: Sending characteristic definition
4882 - DEBUG: Got a new line: 4
4882 - DEBUG: Cmd completed as true in state 5
4885 - DEBUG: Sending characteristic definition
4899 - DEBUG: Got a new line: 5
4900 - DEBUG: Cmd completed as true in state 5
4905 - DEBUG: Sending characteristic definition
4921 - DEBUG: Got a new line: 6
4921 - DEBUG: Cmd completed as true in state 5
4925 - DEBUG: Sending characteristic definition
4974 - DEBUG: Got a new line: 7
4974 - DEBUG: Cmd completed as true in state 5
4975 - DEBUG: Sending characteristic definition
5000 - DEBUG: Got a new line: 8
5000 - DEBUG: Cmd completed as true in state 5
5005 - DEBUG: Sending characteristic definition
5019 - DEBUG: Got a new line: 9
5019 - DEBUG: Cmd completed as true in state 5
5025 - DEBUG: Sending characteristic definition
5045 - DEBUG: Got a new line: 10
5045 - DEBUG: Cmd completed as true in state 5
5045 - DEBUG: Sending characteristic definition
5061 - DEBUG: Got a new line: 11
5061 - DEBUG: Cmd completed as true in state 5
5065 - DEBUG: Sending characteristic definition
5080 - DEBUG: Got a new line: 12
5080 - DEBUG: Cmd completed as true in state 5
5085 - DEBUG: Sending characteristic definition
5100 - DEBUG: Got a new line: 13
5101 - DEBUG: Cmd completed as true in state 5
5105 - DEBUG: Sending characteristic definition
5985 - DEBUG: Sending characteristic definition
6003 - DEBUG: Got a new line: Option Error: UAT+GATTADDCHAR=UUID=12558
6004 - DEBUG: Cmd completed as false in state 5
6004 - DEBUG: Error setting characteristics!
6005 - DEBUG: Sending characteristic definition
6021 - DEBUG: Got a new line: 14
6021 - DEBUG: Cmd completed as true in state 5
6025 - DEBUG: Set new BLE state: 6
6035 - DEBUG: Sending gap advert data cmd
6042 - DEBUG: Cmd completed as true in state 6
6042 - DEBUG: Set new BLE state: 7
6045 - DEBUG: Resetting BLE to enable new settings.
6045 - DEBUG: Set new BLE state: 8
6046 - DEBUG: Cmd completed as true in state 8
7155 - DEBUG: Set new BLE state: 10
7159 - DEBUG: Cmd completed as true in state 10
7169 - DEBUG: Cmd completed as true in state 10
7179 - DEBUG: Cmd completed as true in state 10
7189 - DEBUG: Cmd completed as true in state 10
7199 - DEBUG: Cmd completed as true in state 10
7209 - DEBUG: Cmd completed as true in state 10
7219 - DEBUG: Cmd completed as true in state 10
7225 - DEBUG: Set new BLE state: 11
7235 - DEBUG: Set new BLE state: 13
7239 - DEBUG: Got a new line: 0x0,0x0
7239 - DEBUG: Cmd completed as true in state 13
7240 - DEBUG: Set new BLE state: 11
7246 - DEBUG: - Updated timeRunning
7249 - DEBUG: Cmd completed as true in state 11
7256 - DEBUG: - Updated bleThrBrkLevels 2
7261 - DEBUG: Cmd completed as true in state 11
7266 - DEBUG: - Updated bleTrqReqAct 1
7269 - DEBUG: Cmd completed as true in state 11
7286 - DEBUG: - Updated bleThrBrkLevels 2
7292 - DEBUG: Cmd completed as true in state 11
7298 - DEBUG: - Updated bleThrottleIO 9
8006 - DEBUG: - Updated timeRunning
8009 - DEBUG: Cmd completed as false in state 11
8016 - DEBUG: - Updated bleThrBrkLevels 2
8021 - DEBUG: Cmd completed as true in state 11
8026 - DEBUG: - Updated bleThrottleMap 10
8031 - DEBUG: Cmd completed as true in state 11
8036 - DEBUG: - Updated bleThrBrkLevels 2
8041 - DEBUG: Cmd completed as true in state 11
8046 - DEBUG: - Updated bleDeviceEnable 13
8051 - DEBUG: Cmd completed as true in state 11
8056 - DEBUG: - Updated bleThrBrkLevels 2
8061 - DEBUG: Cmd completed as true in state 11
8245 - DEBUG: Set new BLE state: 13
8248 - DEBUG: Got a new line: 0x0,0x0
So, where does that leave you? Well, actually the first unit I tried did nothing because it was a UART version of the board. You see, there were many versions of the GEVCU6 design before we settled upon the latest one. First we used very cheap BLE modules that were not configurable - they just were BLE to UART chips. Then we switched to Adafruit but the UART version. Then we switched to the SPI version to try to get more speed. I believe you must have the newest, SPI version or you wouldn't get anything at all. With the UART version youd be stuck at state 2 forever trying to set the power level. Anyway, so you probably have the newest board version but something is still not working. First of all, use the DEV branch of GEVCU6 because it is newer and has updates compared to the master branch. That's the version I'm testing with. Then, just to be sure, use the Adafruit library I've put here: www.savvycan.com/Adafruit_BLE_SPI.zip
Between those two things it ought to work because I did just test and was able to get to a stable state and see it with the Adafruit android app.
Lastly, if you've already modified things elsewhere in the code and don't want to overwrite all your changes, then try grabbing just adafruitBLE.cpp and adafruitBLE.h from the DEV branch. Those two files should be the only ones you really need to fix BLE but there were a LOT of BLE related commits between MASTER and DEV so I can't say for 100% sure nothing changed outside those files but it shouldn't have. It is intentionally object oriented and segmented.
I downloaded and installed the Adafruit library. Nothing much changed, just a new error. I'll try the DEV version of GEVCU tomorrow. Are most of the changes to the AdafruitBLE files, or are they more widespread?
41361 - DEBUG: Set new BLE state: 5
41388 - DEBUG: Sending characteristic definition: TimeRunning
41412 - DEBUG: Got a new line: Option Error: DATATYPE=2
41414 - DEBUG: Cmd completed as false in state 5
41416 - DEBUG: Error setting characteristics!
41428 - DEBUG: Sending characteristic definition: TimeRunning
42269 - DEBUG: New checksum: BF
42588 - DEBUG: Sending characteristic definition: TimeRunning
42611 - DEBUG: Got a new line: Option Error: UAT+GATTADDCHAR=UUID=12545
42612 - DEBUG: Cmd completed as false in state 5
42614 - DEBUG: Error setting characteristics!
42628 - DEBUG: Sending characteristic definition: TimeRunning
42649 - DEBUG: Got a new line: Option Error: DATATYPE=2
42651 - DEBUG: Cmd completed as false in state 5
42653 - DEBUG: Error setting characteristics!
I got the DEV code and copied AdafruitBLE into my project. It didn't help. It doesn't look like there are any changes to other modules that would affect Bluetooth functionality. Can you zip up all the code and libraries you are testing with so I can verify that it works with the hardware I have? If it does, I can back apply my changes.
Here's my copy of the GEVCU6 code though it ought to be the same as the GITHub version: www.savvycan.com/GEVCU6.zip
And, you already have the AdafruitBLE library I'm using. Between those two things those are the only two pieces of code I could possibly have that would be different.
So, if it still doesn't work then you have the same code and you tried two different BLE modules so that pretty much leads to suspecting the GEVCU board itself. That's not an ideal situation but maybe there could be something else you could try.
In the Adafruit_BLE_SPI library I sent before there is a line that sets up the SPI speed. It is set to 3Mhz which is under the 4MHz upper limit for the BLE module but since it looks like you're getting comm errors you might try lowing the speed to 1Mhz to see if things improve. BluefruitLE_SPI.cpp on line 45 you'll find the SPI set up. Change the 3 to a 1 and try reloading the IDE and recompiling everything. This will vastly slow down the SPI comm and might help if you aren't getting as stable of a connection as you should.
Thanks. I reset the SPI speed to 1000000 and recompiled my code, but that didn't make any difference. Then I tried your sketch. At first it wouldn't run properly, but I discovered that the verbose setting was causing the serial port to disconnect. I set verbose off and tried your sketch again (still with the SPI speed set to 1000000). Now it runs ok, but with the same errors regarding sending the characteristic definition. It looks like the GEVCU itself might be the problem. How do you suggest proceeding from this point?
Is the behavior of the verbose setting indicative of anything? I assume it works for you?
It causes the serial port to disconnect? That shouldn't happen. I run it like that with the super verbose logging and it works fine. You kind of want all that logging when testing like this so you can see what is going on. I guess you're going to have to make sure that everything is correct hardware-wise. Try different USB cables, try it from a different PC. The GEVCU board should be perfectly capable of outputting an avalanche of debugging info on the usb serial port so if it isn't working then something is wrong on the PC side, the cord, or the GEVCU. And, you'll have to rule the other two out.
I have already tried several USB cables. I don't have another PC currently available. I am using a Surface Pro with Windows 10 Pro. I don't think there are any issues with the serial port.
The problem is not related to the volume of logging either; the disconnect happens even if GEVCU logging is set to level 3. I get one heartbeat dot on the serial output, then the connection drops (Error 22), then the GEVCU begins to reboot continuously. I get this rebooting behavior whenever ble.begin(true), even when the serial cable is not connected, so I'm pretty sure it's not a problem with my PC. The behavior is consistent with either of the two Bluetooth modules or, in fact, with no Bluetooth module attached.
Here is the log. The connection drops right after the first heartbeat dot.
Build number: 1070
5002 - INFO: TWI init ok
5002 - INFO: add MemCache (id: 0x5002, 0x20072D20)
5007 - INFO: Device ID: 0x5000 was found in device table at entry: 5
5016 - INFO: Checksum matches. Value: 0xED
5017 - INFO: Using existing EEPROM system values
LogLevel: 1
5020 - INFO: Running on GEVCU 6.2 hardware
5022 - INFO: Trying to wait ADC1 as ready
5023 - INFO: ADC1 is ready. Trying to enable clock out
5026 - INFO: CAN0 init ok. Status = 0x2100C0 Speed = 500000
5028 - INFO: CAN1 init ok. Status = 0x2100C0 Speed = 500000
5030 - INFO: SYSIO init ok
5031 - INFO: add: Heartbeat (id: 0x5001, 0x200746E8)
5032 - INFO: Initializing Fault Handler
5034 - INFO: Device ID: 0x1031 was found in device table at entry: 2
5037 - INFO: Device ID: 0x1033 was found in device table at entry: 6
5040 - INFO: Device ID: 0x1032 was found in device table at entry: 7
5043 - INFO: Device ID: 0x104F was found in device table at entry: 8
5046 - INFO: Device ID: 0x1034 was found in device table at entry: 9
5049 - INFO: Device ID: 0x1000 was found in device table at entry: 10
5052 - INFO: Device ID: 0x1002 was found in device table at entry: 11
5054 - INFO: Device ID: 0x1003 was found in device table at entry: 12
5062 - INFO: Device ID: 0x100F was found in device table at entry: 13
5065 - INFO: Device ID: 0x1050 was found in device table at entry: 14
5067 - INFO: Device ID: 0x1001 was found in device table at entry: 15
5070 - INFO: Device ID: 0x2000 was found in device table at entry: 16
5073 - INFO: Device ID: 0x2100 was found in device table at entry: 17
5076 - INFO: Device ID: 0x650 was found in device table at entry: 18
5079 - INFO: Device ID: 0x1041 was found in device table at entry: 19
5082 - INFO: Device ID: 0x4400 was found in device table at entry: 20
5085 - INFO: - PowerKey created.
5086 - INFO: Device ID: 0x700 was found in device table at entry: 3
5090 - INFO: Device ID: 0x3000 was found in device table at entry: 4
5092 - INFO: add device: PotThrottle (id: 0x1031, 0x20074700)
5101 - INFO: Checksum matches. Value: 0x7A
5104 - INFO: Checksum matches. Value: 0x7A
5105 - INFO: POTACCEL - Valid checksum, using stored config values
5116 - INFO: Checksum matches. Value: 0x95
5118 - INFO: Valid checksum, using stored config values
5120 - INFO: MaxTorque: 3000 MaxRPM: 6000
PRELAY=0 - Current PreCharge Relay output
MRELAY=1 - Current Main Contactor Relay output
PREDELAY=6000 - Precharge delay time
PRECHARGING...DOUT0:0, DOUT1:0, DOUT2:0, DOUT3:0,DOUT4:0, DOUT5:0, DOUT6:0, DOUT7:0
5132 - INFO: attached CanObserver (0x20074B24) for id=0xF9, mask=0x0, mailbox=2
5135 - INFO: add device: ELM327 emulator (id: 0x650, 0x20074E00
5137 - INFO: - add device: AdaFruit BLE (id: 0x1041, 0x20074EE0)
5139 - INFO: - Initializing ADAFruit BLE bluetooth device...
5152 - INFO: - Button press
5152 - INFO: - PowerKey Now setting up.
5154 - INFO: attached CanObserver (0x200751C0) for id=0x15, mask=0x7F, mailbox=3
5157 - INFO: add device: VehicleSpecific (id: 0x3000, 0x20075238)
5159 - INFO: System Ready
5160 - INFO: ADC chips 2 and 3 have been successfully started!
5192 - INFO: Starting precharge sequence - wait 6000 milliseconds
5274 - INFO: - SDOResponse
5274 - INFO: - SDOResponse
5275 - INFO: - SDOResponse
5364 - INFO: - SDOResponse
.
So, the conclusion I have reached is that the issue described above has nothing to do with serial communications; when verbose is true, it is causing the GEVCU to crash and go into a reboot loop. Where do we go from here?
Well, it's certainly getting complicated. It's never fun when it works on my end and not yours. Let's try this. Download this: www.savvycan.com/GEVCU6_Flasher.zip
I just compiled that version of GEVCU6 myself. There are scripts in there that should allow you to upload my firmware to your GEVCU to see if it works. If it does then there's a problem on your end with compiling the program properly. It could a bad library, it could be a bad install of the Arduino Due files, it could be that I've modified my Arduino Due core files (which I did) and you really need those changes for some reason. I didn't think anything I did made any difference to GEVCU but there's that possibility. The Arduino Due core files have all but been abandoned by Arduino and there's very little chance they'll get updates anymore. So, when I want to change things they end up as local changes and not persisted to the official distribution. I know I made edits to the low level USB code. If my version works we might have to suspect that something I did fixed a glitch in the official core files. In that case I'll probably have to fork the official files and figure out what I changed and change it in my fork so that other people can pick up my hacks to the files.
Ok, I applied the flash and got the below results. After the last line of the trace the GEVCU went into a reboot loop. I tried it with both bluetooth modules, same results. right down to the timestamp.
1593 - DEBUG: ThrottleRequested: -693 TorqueRequested: 0
1595 - DEBUG: CAN Command Frame: 0xC0 0xE1 0xF7 0x0 0x0 0x0 0x0 0x0
1633 - DEBUG: ThrottleRequested: -700 TorqueRequested: 0
1635 - DEBUG: CAN Command Frame: 0xC0 0xCC 0xF7 0x0 0x0 0x0 0x0 0x0
1644 - DEBUG: VS Tick Handler
1673 - DEBUG: ThrottleRequested: -700 TorqueRequested: 0
1675 - DEBUG: CAN Command Frame: 0xC0 0xCC 0xF7 0x0 0x0 0x0 0x0 0x0
1713 - DEBUG: ThrottleRequested: -700 TorqueRequested: 0
1717 - DEBUG: CAN Command Frame: 0xC0 0xCC 0xF7 0x0 0x0 0x0 0x0 0x0
1744 - DEBUG: VS Tick Handler
1753 - DEBUG: ThrottleRequested: -700 TorqueRequested: 0
1756 - DEBUG: CAN Command Frame: 0xC0 0xCC 0xF7 0x0 0x0 0x0 0x0 0x0
1793 - DEBUG: ThrottleRequested: -693 TorqueRequested: 0
1796 - DEBUG: CAN Command Frame: 0xC0 0xE1 0xF7 0x0 0x0 0x0 0x0 0x0
1833 - DEBUG: ThrottleRequested: -693 TorqueRequested: 0
1837 - DEBUG: CAN Command Frame: 0xC0 0xE1 0xF7 0x0 0x0 0x0 0x0 0x0
1844 - DEBUG: VS Tick Handler
1873 - DEBUG: ThrottleRequested: -693 TorqueRequested: 0
1876 - DEBUG: CAN Command Frame: 0xC0 0xE1 0xF7 0x0 0x0 0x0 0x0 0x0
1913 - DEBUG: ThrottleRequested: -693 TorqueRequested: 0
1915 - DEBUG: CAN Command Frame: 0xC0 0xE1 0xF7 0x0 0x0 0x0 0x0 0x0
1944 - DEBUG: VS Tick Handler
1953 - DEBUG: ThrottleRequested: -700 TorqueRequested: 0
1955 - DEBUG: CAN Command Frame: 0xC0 0xCC 0xF7 0x0 0x0 0x0 0x0 0x0
1993 - DEBUG: ThrottleRequested: -693 TorqueRequested: 0
1995 - DEBUG: CAN Command Frame: 0xC0 0xE1 0xF7 0x0 0x0 0x0 0x0 0x0
.2033 - DEBUG: ThrottleRequested: -693 TorqueRequested: 0
2037 - DEBUG: CAN Command Frame: 0xC0 0xE1 0xF7 0x0 0x0 0x0 0x0 0x0
2044 - DEBUG: VS Tick Handler
2073 - DEBUG: ThrottleRequested: -693 TorqueRequested: 0
2075 - DEBUG: CAN Command Frame: 0xC0 0xE1 0xF7 0x0 0x0 0x0 0x0 0x0
2113 - DEBUG: ThrottleRequested: -693 TorqueRequested: 0
2116 - DEBUG: CAN Command Frame: 0xC0 0xE1 0xF7 0x0 0x0 0x0 0x0 0x0
2144 - DEBUG: VS Tick Handler
2153 - DEBUG: ThrottleRequested: -693 TorqueRequested: 0
2156 - DEBUG: CAN Command Frame: 0xC0 0xE1 0xF7 0x0 0x0 0x0 0x0 0x0
2193 - DEBUG: ThrottleRequested: -700 TorqueRequested: 0
2196 - DEBUG: CAN Command Frame: 0xC0 0xCC 0xF7 0x0 0x0 0x0 0x0 0x0
2233 - DEBUG: ThrottleRequested: -700 TorqueRequested: 0
2237 - DEBUG: CAN Command Frame: 0xC0 0xCC 0xF7 0x0 0x0 0x0 0x0 0x0
2244 - DEBUG: VS Tick Handler
2263 - DEBUG: Set new BLE state: 2
2264 - DEBUG: Sending power level cmd
2273 - DEBUG: ThrottleRequested: -693 TorqueRequested: 0
2275 - DEBUG: CAN Command Frame: 0xC0 0xE1 0xF7 0x0 0x0 0x0 0x0 0x0
2278 - DEBUG: Cmd completed as true in state 2
2280 - DEBUG: Set new BLE state: 3
2283 - DEBUG: Sending device name cmd
2292 - DEBUG: Cmd completed as true in state 3
2295 - DEBUG: Set new BLE state: 4
2296 - DEBUG: Sending add service cmd
Unfortunately it all points to some sort of hardware issue. It very well could be the GEVCU itself. You're now running the exact same binary I am and it works on my end but not yours so it has to be hardware not software. I wonder if a power supply could be weak or something. That might explain why it would start to boot loop as soon as the BLE module was getting configured. Or there could be something else wrong. But, I have to suspect it is hardware related in some way.
I'm using a 5A power supply. What does GEVCU require? Also, what is the version on the Bluetooth firmware you are using?
Well, GEVCU shouldn't require even an amp on the 12V input. You can power it directly from USB but it might get a little bit too much with the BLE module installed. Still, that's 500ma at 5V for a USB cord. So, 1A at 12V would be plenty. What I was referring to are the power supplies on the board itself. There are multiple voltage regulators and if one of them were bad or marginal it could cause a reboot. Or a bad solder connection somewhere. It's hard to say but it seems like a hardware issue. It's difficult to pinpoint exactly what remotely. I'm currently using the 0.8.0 firmware on the BLE module but I started with 0.7 something. I forgot to check. But, it worked on both versions so I don't think the BLE firmware version makes a lot of difference.
Ok, thanks. The Bluetooth modules I have are 0.6.5, so that may be the problem. I haven't been able to upgrade either of them. I'm getting DFU DEVICE DISCONNECTED from LE Connect during the upgrade, then it fails. Lately I have been getting a hang on "Checking updates..." during the connection. I posted an item on the Adafruit forum, but no response. Any insights?
I bought yet another Bluetooth module, and this one seems to work. I still can't start it in verbose mode, but I was able to update it to 0.8.0 and the characteristic definitions and updates seem to be working. I am trying to use the ELM327 interface with the Torque android app, but it's not working. I have paired the Bluetooth module with the tablet but Torque won't connect to it. Is there something I need to do to get this to work? What software have you used successfully with the ELM327 emulation?
Well, it's strange that you could have gotten 2 bad modules in a row. But, good that you got it mostly working. Now, the ELM327 emulation I think was done with a previous bluetooth module. You can't really do ELM327 over BLE. The ELM327 emulator code thus sends to a serial port that the older bluetooth module listened to. In theory Torque could access ELM327 devices over WiFi which still doesn't quite work out for you with a standard GEVCU6. I believe we left in code to respond to OBDII queries on CAN so you could add an ELM327 compatible dongle to your CAN bus.
Thanks for the reply, but I'm a bit at sea here. We assumed that since there was an ELM327 emulator that we could use the Bluetooth module to access it. The Torque app has been upgraded to work with BLE (at least according to their docs). Are you saying that that the ELM emulator won't work with the Adafruit Bluetooth module? If not, then what will work with it? Is there any Bluetooth client software that will work with GEVCU in its current configuration? Is there additional development that would make this work?
We need a way to implement a dashboard and collect operational data from the vehicle using Torque or something like it. What options do we have for this using GEVCU, including the client software? If we need an ELM compatible CAN/Bluetooth module, can you recommend one?
Sorry if I'm being stupid, but this is a surprise and not a good one.
Hmm, I didn't know Torque was starting to support BLE. Perhaps that would be an approach. I'll have to look into it. The ELM327 stuff is brought over from previous revisions of the board where we did use a standard bluetooth module. But, if BLE will work then I can probably get the Adafruit module to work with Torque. Otherwise an OBDII connected bluetooth adapter could connect to torque and turn the Torque requests into CAN messages which the GEVCU6 board could then respond to.
Ok, thanks. Ideally we would like Torque to work with the BLE adapter, which it says it will do (v1.8.199).
https://torque-bhp.com/forums/?wpforumaction=viewtopic&t=3.0
Let me know if there is anything I can do to support your effort.
Have you had a chance to look into this?
Great news. Please keep me apprised.
I appreciate your attention to this. For planning purposes, it would be helpful to know in what timeframe you think this might be resolved.
Thanks.
I'm hoping that no news is good news?
Well, it isn't bad news per se. I did look into it more and it really does seem pretty straight forward. But, I just haven't had any time to actually attempt it. Perhaps this weekend I might get some testing done.
Excellent, thank you.
Any update?
Yeah, I'm sorry it's taking so long. Lots and lots of projects are in the works right now. I actually did all the coding I think it should take to make it work but I haven't tested it yet. So, hopefully it works the first try and everything is good. Though, is that likely? Probably not. I will try to remember to grab a GEVCU6 with BLE module and test. I don't actually have as many of them as you might think so I've got to go searching to find a good one and not some pre-release broken hardware.
Hi Collin,
I hope the new year finds you well. In your last communication you said you had completed the coding and testing is pending. Great news! If I can be of any help in testing please let me know. Looking forward to hearing the current status.