If you use the DFU website to upload 0x8000000.bin from the Orba, edit it, then download it again, you can change the console messages.
Unfortunately I still can't see how to change the values.
I now think that in console mode we're probably talking to a program running on the STM32.
To recap, the DFU website lists four entries:
DFU: cfg=1, intf=0, alt=0, name="@Internal Flash
DFU: cfg=1, intf=0, alt=1, name="@Option Bytes /0x1FFF0000/01*048 e"
DFU: cfg=1, intf=0, alt=2, name="@OTP Memory /0x1FF07800/01*528e"
DFU: cfg=1, intf=0, alt=3, name="@Device Feature/0xFFFF0000/01*004 e"
The first one is 0x8000000.bin, the one we can edit to change console commands, though values remain obscure, and the file doesn't change when you do things like change quantise mode inthe console or record notes. In other words, it looks like it has the console program, but not the loop data.
The others only have a few bytes each; low-level processor management stuff.
...but what about 0x20010000.bin...? That's the other slightly more substantial one that gets uploaded at the start of the flash-from-file process.
It doesn't appear in that web list, but I've found that you can still upload it from the Orba via a Windows command prompt via dfu-util. The flash log has:
dfu-util.exe -d 0483:df11 -a 0 -s 0x20010000:force -D \0x20010000.bin
...where "D" means "Download", or "Send to Orba". But if you change that to "-U" for "Upload", you can grab it.
I just tried:
1) Upload it
2) Change quantisation mode from console
3) Upload a scond copy
4) Record some notes
5) Upload a third copy
...and finally these files are changing. I can tell that much from the "Compare" plug-in in Notepad++
...but it's all garbage and weird characters. I'm sure this is the wrong view and I should be using a hex editor or something. (?)
Here's two versions of the file; the only thing I did deliberately was to toggle quantisation in the console, but more might have happened than that. @Subskybox I don't know if you might have a clearer idea what kind of differences there are...? Is there some other view or decoding that I should be using for these .bin files...?
1) Initial state
2) Toggle quantise
3) Record four lead notes
Here's another set of three with an empty sequence which might be simpler.
1) Initial state, quantise on
2) Toggle off
3) Toggle back on
...I think I've now managed to compare the files in hex view, but there are changes all over the place.
Back to the drawing board...
(...also been trying to use esptool.py to recreate this part of the log which talks about 4MB Flash memory, but drawn a blank on that as well...)
20 Jun 2022 9:29:59pm - esptool.py v2.8-dev
20 Jun 2022 9:29:59pm - Serial port \\.\COM12
20 Jun 2022 9:29:59pm - Chip is ESP32D0WDQ5 (revision 1)
20 Jun 2022 9:29:59pm - Features: WiFi, BT, Single Core, VRef calibration in efuse, Coding
20 Jun 2022 9:29:59pm - Crystal is 40MHz
20 Jun 2022 9:29:59pm - MAC: 8c:aa:b5:9b:4c:10
20 Jun 2022 9:29:59pm - Configuring flash size...
20 Jun 2022 9:29:59pm - Auto-detected Flash size: 4MB
There's documentation available on these files like "partitions_singleapp.bin"; they're evidently part of the ESP32 programming environment, but that's getting a bit too deep for me.
https://esp32.com/viewtopic.php?t=2528
I've finally managed to get esptool.py to work.
I was convinced that the ESP32 would only respond if was in programming mode, but I couldn't figure out how to get it into that state.
Then I remembered the log from the good old B console command, "Commencing BLE serial pass-through with ESP32 in programming mode." (Attached)
Some of these commands just seem to put the Orba to sleep; no lights, no DFU mode, nothing. But it occurred to me that they might quietly have gone into programming mode. So I tried running one ofg the standard esptool.py commands, retrieving the MAC address, immediately after "B" in the console...never got this (or any other esptool commands) to work before, and bingo. :-)
Whether it's actually useful or not is another matter, but it's a new channel of communication with the Orba, and it explains why some of the console commands put it in a trance.
The attached console log is "1" for looper info followed by "B" for "Commencing BLE serial pass-through with ESP32 in programming mode." I was wondering whether any of the values reported by that command might relate to the missing quantisation values like "quantStartSnapTicks".
It finishes up by waiting for a download; in other words, it wants some kind of file transfer, which we might be able to do with esptool if we can knew what it was after.
(Log file)
...referring back to the flash log, the three files that get sent to the Orba immediately after that point are delorean.bin, bootloader.bin and partitions_singleapp.bin. I think the last two seem to be standard filenames that crop with up with ESP32 programming, whereas delorean is the Orba's special one.
@BJG145 said: " I don't know if you might have a clearer idea what kind of differences there are...?"
Unfortunately, I don't. I can tell you that this .bin file is likely just a memory dump that can be downloaded/uploaded from/to the device. It definitely contains what I would consider compiled C code. Disassembling compiled C would be almost as cryptic as the bin itself. It might be best to hunt through the bin file looking for any bytes that hold the values 120, 240 or 240. It might be possible to zero in on where the default values are defined. Since this is C, there won't be any indication of variable names so we need to hunt by value rather than by name. There are likely numerous hits if you search for those bytes, but if we're lucky they might appear close together which would be an area of the code where all these variables get initialized.
...hmm, at first glance I'm not sure how useful this is going to be. While it's in that state it seems you can read/write any section of the 4MB Flash memory, but judging by this "partition table" in the console log the contents don't look very exciting. I was hoping to see an entry labelled: "Secret quantization parameters" or something. :-P
I (87) boot: SPI Flash Size : 4MB I (91) boot: Partition Table: I (95) boot: ## Label Usage Type ST Offset Length I (102) boot: 0 nvs WiFi data 01 02 00009000 00006000 I (110) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (117) boot: 2 factory factory app 00 00 00010000 00100000 I (125) boot: End of partition table
This isn't very interesting, but just for completeness, it's the console log for the alternative "Commencing BLE serial pass-through with ESP32 in normal mode". These are probably just for debugging Bluetooth data.
@BJG145 Here is a shot in the dark... I hunted through 0x8000000.bin and found an area that I believe might be where the constants are defined. I changed a value of 120 to 121 and 240 to 241. If you can upload this and then check the loop info maybe we'll have a hit?! It's a needle in a haystack but it's an educated guess. :)
...thanks for looking...I didn't see a change there unfortunately. I think 0x8 stays static, and it's 0x2 that changes unpredictably. However, I'm not sure if even 0x2 has a quantise on/off setting, because I tried it the other way round; saving an 0x2, flipping quantize, then sending the saved 0x2 back to the Orba, but that didn't change it back.
It would be interesting to find them, but maybe we don't really need them. A couple of things I'd like to try would be to see if there's a more accessible way for people to turn it on/off without needing the console, and maybe creating a cool demo song which is partly 'constructed' rather than recorded. I'll need to spend a bit more time to try and understand how to string a pattern of notes together from scratch using eventData. I might try messing around with those 'pattern' tags as well...:-)
A few more thoughts. I suspect Artiphon will update the Orba App in conjunction with the release of the Orba 2. Maybe they will expose some of this since they advertise the Orba 2's features to include:
Andrea Mannocci
This thread is intended to gather the feedback of Orba tinkerers.
27 people like this idea