[cags12]

Hi – I am 80% happy with my Widi-Bud. Everything works great as expected except when receiving long SysEx messages > 256 Bytes. (I have not tested sending long ones but suspect is is the same)

I have done A LOT of troubleshooting for the past 3 days thinking that the Windows driver was causing issues as it is know it cannot handle SysEx messages that are spread across multiple buffers.

However, it turns out that the same issue happens in Linux (I haven’t tested MAC yet – since I do not own one, I will try to install a Hackintosh). I am sure the Alsa Linux driver is well able to handle the long SysEx message as I tested with another MIDI interface successfully.

I am also 100% sure my MIDI BLE transmitter (QuiccoSound mi.1) is transmitting the whole SysEx message. I was able to prove it from my Android and iOS device using their native BLE adapter. In this case I received the complete message.

I used MIDI-OX (Win), USBpcap (Win), USBmon (Linux) and AMIDI (Linux alsa util) for the troubleshooting. I do not see the first 256 Bytes of the 340 Bytes I am trying to Dump from my MIDI controller when I examine the captures. Strangely enough, I do see the next 84 Bytes that I suspect are stored in the next bulk of data coming into the internal buffer.

The only conclusion is the Widi-Bud having issues processing a SysEx message that is bigger than 256 Bytes thus not delivering it completely to the USB driver. Could it be that the Bud’s buffer is just 256 Bytes long? If cannot be changed/increased, the fix then I see should be to deliver the Data received (regardless it has not reached to a “F7” [SysEx end]) and append what comes next to complete the SysEx message.

Could this be fixed with a firmware update? I really need to be able to send the SysEx message for the Widi Bud to be functional in my application.

I can provide troubleshooting files.

I sent an email a few days ago when I thought it was a Windows driver issue, no reply yet.

[Zhao Yitian]

Dear Cags12, thanks for your message.
Sorry, we missed your email from our system, we will check it again.
For above technical issue, our CTO will check it and try to find answer for you asap.

[cags12]

Hi Zhao, no problem, it gave me time to do my own troubleshooting and progressing on the investigation.

Please feel free to contact me on this Forum topic and/or over email.

Looking forward for your CTO reply 🙂

[jerome]

Hi
I’m Jerome, CTO at CME.
Indeed the buffers for both RX and TX are 256 bytes.
This cannot be increased too much due to in-IC limited memory.

Your suggestion to forward incoming SYSEX directly without buffering is not possible, as receiving and forwarding are done in separated threads. Incoming data require buffering.

In order to understand, in which direction are you receiving these long SYSEXs ?

USB Rx to BLE Tx
or
BLE Rx to USB Tx

Please let me know so I can try to see if buffers could be increased at least in one direction.
Regards

[cags12]

Hi Jerome,
Thank you for your reply and looking into this.

I did not really mean forwarding the SYSEX directly without buffering. What I meant is to forward the data from the buffer as it is (sort of bit by bit). The IC can maintain a status flag (accessible to both threads) that gets set up as soon as it sees a SYSEX start “F0”, this would indicate to keep forwarding data from the buffer (even multiple times) as it is, until it sees the SYSEX end “F7”. At this point the flag gets unset and then going back to normal mode of operation.

I obviously do not know all the ins and outs and how the internal driver is programmed but that is just an idea on how I imagine to solve this limitation. If it is possible, It will even allow super long SYSEX messages with no need to increase the internal buffers. Does it make sense?

To answer your question:
I am receiving the long SYSEXs “BLE Rx to USB Tx”. Normally the SYSEX Dumps are done from the controller. However, the other way around is also important when restoring the Dumps back to the controller. In my specific application “BLE Rx to USB Tx” is more important (for now).

If my suggestion above about how to handle the buffering is not possible; then I have another idea on how to manage the buffer size for Rx and Tx.

The Widi Plus application can have a “settings” section where from a pool of buffer memory of the IC we can slide Tx and Rx. Say we have Tx+Rx=512 Bytes, the slide setting could allow removing buffer memory from Tx to allocate to Rx; ie: Tx(112)+Rx(400)=512 Bytes. This would “mitigate” a bit the situation and would allow the user to select what direction is more important in a give time.

How much more memory can we squeeze from the IC’s internal memory to allocating to the buffers?

Thanks again.

[jerome]

Hi
Thanks for your suggestions, anyway, the internal buffers are circular buffers.
For every incoming MIDI message, we need to know where it starts and where it ends.
Setting a flag for SYSEXs is not possible, for instance :
– We receive 10 Notes ON events from USB -> all are stored in BLE TX buffer (30 bytes)
– We start sending these 30 bytes to BLE TX
– Once BLE TX is full (after 20 bytes), we have to wait before sending the 10 remaining bytes, until it becomes ready again.
– What happens SYSEXs are received now, and not included in the buffer ?
-> If we start sending these incoming SYSEXs without buffering them, the resulting BLE TX will be corrupted.

BLE is slower than USB, that’s why it requires buffering. BLE packets are 20 bytes, once a packet is full, we have to wait until it becomes ready again.
Not so easy then.

I’ll check into the source code if I can increase buffers.
Regards
Jerome

[cags12]

Hi Jerome,

If you do not mind, can we continue this conversation over email? I still may have some technical suggestions that we can discuss and you may or may not consider. Perhaps something you would not like to post publicly.

Plus, the fact that I see on my USBpcaps the leftover (now rubish) data of the truncated SysEx message may indicate a possible bug. They are not proper MIDI messages. I’d like to send you this debug.

We can report back to this post the final results for other users to see.

BTW – thank you for looking at increasing the buffers, that for sure will help a lot.

Regards,
Christian

[jerome]

Christian
Yes, lets discuss by email.
[email protected]
Jerome

[MMV]

Hi my name is Mary and I’ve been following this topic for a while waiting for a post with a solution. Has there been any progress?
I got a few Widi Buds with the intention of solely use it to send and receive System Exclusive and NRPN messages within the studio to avoid cluttering. There was not any mention of this limitation anywhere in the specifications 🙁

I hope there is a solution

[Author]

Posts