Open biomurph opened 3 years ago
Just successfully uploaded the Melody v6.1.1 to Tympan E BC127 radio module. Then I programmed the Teensy 4.1 with the RenameBT.ino code. This is the serial output from that sketch
RenameTypmanBT. Starting... Switching Tympan RevD BT module into command mode... Should be in command mode. Clearing buffers. Sending carraige return. ERROR 0x0012 Should have gotten 'ERROR', which is fine here. Restoring factory defaults... BlueCreation Copyright 2016Melody Audio V6.1.1 HDBuild: 14861OKBlueCreation Copyright 2016Melody Audio V6.1.1 HDBuild: 14861 Reset should be complete. Did it give two 'OK's, an ID blurb, and then 'READY'? Begin renaming process. Getting BT name... Response = NAME=BC-1C1427OK Processing name info... Desired New BT Name = TympanE- Setting New BT Name...TympanE- OKOKNAME=TympanD-OK Name setting complete. Did it return the desired name? Setting GPIOCONTROL mode to OFF, which is what we need... ERROR 0x001AOK Changing into transparanet data mode... ERROR 0x0012 BT Setup complete. *** Now entering BT <-> USB Echo mode...feel free to send messages back and forth.
V5.5 is our baseline, not V6.
I have been digging around and I can't find an easy fix for this. I put up a post on the Sierra forum https://forum.sierrawireless.com/t/change-melody-firmware-v6-1-5-hd-to-v5-5rc11/24042
I think that the Melody DFU Tool might be an option, but will have to create a Teensy code that will interface with it. I think that the Melody DFU wants to send the initial signal that will put the module into DFU, and there is some kind of back-and-forth necessary for it to operate. This is all doable, but it would be good to know if it is a possibility and hopefully the forum will respond positively.
It does look like any update on our end to interface with the newer firmware is not trivial, but it is doable.
It's a problem working on from a firmware base that is 4 years old and made by a company that doesn't exist any more (Blue Creation, that is).
I'm watching the forum. I'll start work on getting the Teensy side of the module communication working clearer in the RenameBT sketch.
Sorry that I missed your very obvious earlier posts about V5.5 not being feasible due to it being the HD variant. I was trying to do too many things at once. My bad.
In the past, I've found little help from Sierra themselves on these products, so I'm not hopeful for your request. My fingers are crossed, but I'm not hopeful.
If it turns out that the new module is not the same hardware as the old one, and that it simply can't host the V5 firmware, that's an unfortunate problem. Suddenly, we'll have an unplanned hard break in our bluetooth compatibility between RevD and RevE that we'll have to deal with. Ugh.
You should probably send us a unit so that we can get a feel for the magnitude of the problem. We could put V6 on one of our units, but I fear that we wouldn't capture all of the nuance of what might be different with the hardware. If we're going to do some testing to figure out what the problem looks like, we should be working with the actual production hardware.
Can you send us a unit?
Yes! It will go out in tomorrow's delivery complete with teensy, etc
For RevE, I got the new BC127 module to work.
I had to upgrade:
Unfortunately, the BLE message format is a little different between V5.5 and V7.3HD, so one has to tell the BLE class which version of the firmware you’re using. That’s crappy. Maybe we can be smarter later. Right now it defaults to V7, assuming that you will upgrade all the new RevE to V7.
Note that I did start with trying to be compatible with the V6 firmware that came on the hardware. It seemed to have some message formatting issues that made our end much harder. The V7 firmware went back to some of the message formatting qualities from the V5 firmware, so it was much easier for me.
The new Tympan_Library has only been tested on the single RevE that you sent me and only with the V7.3HD firmware. Also, there is still some stuff in the class that doesn’t quite work (like, most importantly, the method “setupBLE()”). As a result, it is only held in a branch in the repo and not yet merged into either develop or master. For your own trials, you can try out the branch here (after upgrading your firmware to V7.3HD, of course):
https://github.com/Tympan/Tympan_Library/tree/feature_BC127_V7
For my trials, I’ve been using the sketch in the Tympan_Library: “01-BasicGain_wApp”. The only change that you need to do is to bypass the afore-mentioned failure of “setupBLE”. Comment it out and replace it with this:
//ble.setupBLE(myTympan); //original
ble.advertise(true); // new
@chipaudette We have an issue with the BC127. The module that we got in our build is the BC127-HD variant. It came shipped with the Melody v6.1.5 HD firmware.
I followed the instructions on our BC127 firmware up/down grade repo, and went through the process as far as downloading existing firmware from the target (it was not an option to just upload). I got the following error from the DFU Wizard
Then
I tried to upload every version of Melody that we are hosting in the repo, and got the same error. Then, I went to the Melody firmware page at Sierra and it looks like there are releases that are only for the HD variant. The earliest version that they offer is the version 6.1.1 HD. For more about what that means, I looked into the Melody v6 User Guide at the bottom (page 88 on) is a list of the change logs. At least that's something! It says that the HD variant is only starting to be available in Melody 6.1.1.
FYI the
HD
is referring to aptx HD, which is some Qualcomm trademarked nonsense that means the audio is high definition. HERE is a link that talks about the difference it makes.I did try to run the Melody DFU Uploader.exe program but it is not connecting. Likely this is because it tries to tell the BC127 to go into DFU mode, but that is what our arduino dfu firmware is already doing... (?)
In the end, I was able to use the DFU Wizard to upload a clean copy of the Melody 6.1.5 HD firmware to the module.
I'm going to downgrade to the Melody v6.1.1 to see if that makes any difference in our ability to control the module and then report back on this issue thread.