Was there any protocol change to the smart radio data/programming connection? I had a working wireless programming solution using brain-id-in-the-name discovery method, but with latest VexOS (2.1.2), the brain (id=40870) no longer connects to my BTLE peripheral.
The peripheral advertises as “40870-1-6-1-3”, but the brain never tries to connect. I have verified I have “Radio Data” set to “On”. The brain still happily connects to a controller, but the controller uses the other documented advertisement method…
BTW: The SDK mentions (regarding the radio/data versions, 1.3 and 1.6 respectively in my case):
“This will need to match the version of controller software your brains firmware requires” - How do I learn what versions does the brain expect?
The controller, under the latest firmware, seems to be advertising with both Radio and firmware versions of 1.6: 0x11 0x11 0x01 0x06 0xa6 0x9f 0x00 0x00 0x01 0x06, but even if I try to advertise as 40870-1-6-1-6, the brain won’t connect…
Hey @nenik,
We did not change any of the connection logic on the latest Smart Radio firmware update. We fixed a bug in the data transfer logic. I have tested with the Ipad version of modkit and some of my test apps and they seem to no issues connecting. Just FYI the current firmware does not pay attention to the version numbers in the advertisement name. It just has to match the format “UUID-#-#-#-#”. The "#"s can pretty much any number.
So, for some reason, the brain apparently never tries to connect to my device.
I have captured the packets. Whenever I turn on a paired joystick, its advertising packet will get quickly followed by the brain sending ADV_CONNECT_REQ. But the advertising packets from my device never got the brain’s interest.
Paired Joystick advertisement event: (Joy MAC = 20:C5:8F:F3:EF:BD)
20 D6 BE 89 8E 00 15 BD EB F3 8F C3 20 02 01 06 0B FF 11 11 01 06 A6 9F 00 00 01 06 13 2B FD 26 A5
(The VEX Custom tag of: 0B FF 11 11 01 06 A6 9F 00 00 01 06 shows the brain ID of 0x9fa6 = 40870)
My advertisement (Device MAC = D9:E7:7B:F6:1F:DF)
27 D6 BE 89 8E 40 1C DF 1F F6 7B E7 D9 0E 09 34 30 38 37 30 2D 31 2D 36 2D 31 2D 31 03 19 34 12 02 01 05 1C CC F1 27 A5
(you see the name tag is: 0E 09 34 30 38 37 30 2D 31 2D 36 2D 31 2D 31, which decodes as: “40870-1-6-1-1”)
Does the brain with the latest firmware really still react to the ADV_IND with the brain ID in the name?
So the data you are sending looks correct. The biggest difference I am seeing is that Modkit for Ipad puts the “GAP_LOCAL_NAME_COMPLETE”(0x09) section in the ADV_SCAN_RSP packet instead of the ADV_IND. According to the firmware it honestly should not matter. But you may try moving it and see what happens.
Capture from Modkit:
ADV_IND: 26 D6 BE 89 8E 40 1B 84 F5 8D 15 69 49 02 01 1A 11 07 A5 13 EB FA F6 72 57 87 7E 46 05 DB 7E 0F 59 08 BC 77 59 3F A6
ADV_SCAN_REQ: 17 D6 BE 89 8E C3 0C 8E D2 28 F2 17 63 84 F5 8D 15 69 49 11 7F 0A 1C A6
ADV_SCAN_RSP: 21 D6 BE 89 8E 44 16 84 F5 8D 15 69 49 0F 09 37 30 30 30 30 36 2D 31 2D 35 2D 31 2D 31 58 23 80 40 A6
I also noticed that they are advertising the Joystick service in the ADV_IND packet. That is also not necessary. Let me know what you find out.
So I’ve got much further today, not sure which part have I changed (if any, puzzled me says) and the brain now connects well. With the link connected, I can even do the firmware upload from RobotC (extending the communication timeout, enabling non-VEX ports and selecting my custom CDC-ACM port), which is usually the hard part (huuuge transfer).
But I can’t upload even a trivial program. RobotC will talk to the brain for a while (stop programs, see what the brain is), but as soon as RobotC issues a flash read command, the brain doesn’t answer. I’ll try to capture the full communication log and perhaps BT transactions of this later today or tomorrow…
I did try my old demo code from here
and it was connecting to the brain without any problems, obviously no program upload capability using that.
So I finally got some time to capture more packets and the results are surprising. First, let me reiterate that “Firmware Download” from RobotC over my BTLE link works reliably, so the heavy traffic towards brain is fine. But even a trivial program upload fails at ‘VEX IQ Flash Read’ phase (other communication up to this point was rock-solid too). The RobotC message log shows a timeout waiting for the flash read reply:
2899.410 Send Message ; Function: <sysFuncBulkPropertiesRead [0x47]>; length 15; 67 47 04 29 00 01 29 00
00 29 00 0E 29 00 0D
2899.510 Reply message <Reply to ‘SystemFunction’::sysFuncBulkPropertiesRead>
robotType = VEX-IQ/0xE.
firmwareVersion = 10.56/0x420.
nSystemStartOfFlashFileSystem = 0x00034000/0x34000.
addressOfGlobalVariables = 0x20005800/0x20005800. ; length 18: 67(98) …
04 0E 00 00 00 20 04 00 00 00 40 03 00 00 58 00 20
2899.517 Send Message **<StopAllTasks>** ; length 1; 62
2899.614 Reply message **<Reply to 'StopAllTasks'>**; length 1: 62(9D)
2899.664 Send cmd: 'VEX IQ Flash Read' Addr: 0x00034000, Size: 239; Data: C9 36 B8 47 65 06 00 40 03 00 EF 00
2902.008 Send cmd: 'VEX IQ Flash Read' Addr: 0x00034000, Size: 239; Data: C9 36 B8 47 65 06 00 40 03 00 EF 00
2904.352 'VEX IQ Flash Read' message to VEX IQ brain failed
2908.447 COM port '09F66BF0' Device: "COM5" Notification: 'Unregistered'
I first assumed the brain doesn’t answer, though BTLE capture shows it does. I have captured an exchange, where the brain, as the answer to the ATT_Value_Notify(“C9 36 B8 47 65 06 00 40 03 00 EF 00”) starts performing a sequence of ATT_Write_Req, 20B of payload each. Each 20B transaction takes 50ms (2x25, since the first connection event has ATT_Write_Req confirmed on the link layer and the next one has empty PDU that allows the Att_Write_Rsp confirmation) The trouble is, I only see 9-10 such writes, 20B each except for the last one, which is 9B. That makes 149 - 169B transfered, quite short of the 239B expected by RobotC (and likely the reason RobotC doesn’t log the received data at all).
I have confirmed (using a serial logger on the RobotC side) that my device correctly forwards all those bytes from BTLE through the USB-serial.
So at this point, my hypothesis is that the brain is sending the data to the blue SmartRadio too fast and the radio never gets some of the data on the air. I can try shortening the connection interval in case the brain accepts that to increase the available bandwidth. Currently the link gets negotiated at 25ms. What connection interval does the iPad use? Does iPad issue long reads from the brain like RobotC does?
And for the record, I have managed to force the connection interval down to 10ms (initially, the brain connects at 8.75ms, but shortly after requests a change to 27.5ms. But if my device sends a connection parameter update request with 10ms interval, the brain accepts that and updates the rate accordingly).
Even at 10ms interval, I still see only 149B transferred on the 239B flash read, albeit faster (done in slightly over 200ms instead of 500ms).
@levipope Curious if there could be such a timing/buffer overflow issue as I have described on the brain side and why it wouldn’t manifest itself when uploading from iPad…
It looks like the issue you are running into is a buffer overflow on the brain’s radio. The buffers are pretty small (150 bytes) and RobotC does a large read that overflows that buffer. Not sure why that was not happening before though. That buffer has been that size for some time now. The Modkit Ipad app uses smaller buffers to keep the radio from over flowing. I will dig into VEXos on the next revision and see if I can do some throttling of the data on the brain side to keep that from happening.
Thanks for the answer that confirms my suspicion. So either the radio must have scheduled the transfers differently (in parallel to the incoming data?), or the RobotC didn’t use to do large reads on a program upload.
There is no issue on the large transfers in the opposite direction, I can easily perform RobotC firmware update through the BT link, but in that case, it’s the Brain’s radio that controls the transactions.
Looking forward for a fix 