I am using a commercial MidiJet Pro wireless system to send midi instructions from a commercially made controller instrument to an external sister module from the same vendor which converts the pulses into audio.

I have two instrument controllers of similar (but not identical) design, but of different version. Each works correctly when hard wired to its respective sister module.

One - call it Controller 'A' - functions correctly when used wirelessly via the MidiJet and the other - Controller 'B' - fails miserably. I have thoroughly characterized the pulse streams in the case where it works - and that where it fails - to transmit pulses within the stream.

Controller 'A': The pulse count in each stream is preserved through transmission. In a typical pulse train when the system is idle, there are eight pulses. While it sometimes breaks up a midi instruction into two parts (one with three pulses, the second with five pulses for a total of eight), delaying some of the pulses, the midi instrument works correctly even when some of the pulses are delayed.

Controller 'B': In addition to delaying parts of a pulse stream or train as above, the MidiJet consistently drops pulses from the train. There is clearly something different about this system.

I scoped the pulses that are missing in the latter case, but they look virtually the same - i.e. width, levels, frequency, latency, etc. - as in the case that works correctly. It is often the leading pulse in a train that fails, but not always. Sometimes it is a 30 usec pulse that fails to get through the system. Other times a 30 usec pulse is transmitted correctly, and it will drop a 60 usec pulse in the same train. 30 usec is about the narrowest pulse produced by either controller.

I suspect the MidiJet buffers the pulse trains and uses some kind of algorithm to decide whether to transmit the pulse train. (The MidiJet tech support says it buffers but makes no such decision.) But bottom line: it always works correctly with Controller A and always fails with Controller B. I need to determine exactly what is different about Controller B and determine if there is a way to correct the design.

I am located in the SFO Bay Area and could probably benefit from a local expert in midi protocol.

 

You don't mention the physical range?
Could it be that you are too far away and the RX signal is marginal?

Wireless = Radio = not always perfect.

 

No. This is not a range issue. The distance is about 3 or 4 feet. And the result is the same regardless of range. It NEVER works in B and works over wide ranges in A. This is a functionality issue independent of range.

 

Why do you think the two "pulse trains" should be identical? It is possible that it is trying to say something different and that you have misdiagnosed the problem. In any case, unless the manufacturer has a configuration fix for you, your chances of modifying the design are somewhere between slim and none.

 

Well, I don't believe the wireless midi should change the midi byte...how could that be expected to function correctly?

Moreover, controller A does not drop pulses through the wireless. What goes into the transmitter comes out of the receiver. And, it works.

(True controller A sometimes delays a portion of a string, but that doesn't seem to cause a malfunction.)

When you refer to the manufacturer, you mean the wireless manufacturer? Otherwise, the pulses from the two controllers visually look the same. Can't see why one would be transmitted successfully and the other not.

 

I have a wireless DMX unit, it also does not exactly replicate the pulse train.

It sends the data as some type of "symbol" then regenerates the DMX on the other side- with very different timing.
Frustrating because it doesn't work if I send abbreviated DMX packets.

 

Well, I don't believe the wireless midi should change the midi byte...how could that be expected to function correctly?

Moreover, controller A does not drop pulses through the wireless. What goes into the transmitter comes out of the receiver. And, it works.

(True controller A sometimes delays a portion of a string, but that doesn't seem to cause a malfunction.)

When you refer to the manufacturer, you mean the wireless manufacturer? Otherwise, the pulses from the two controllers visually look the same. Can't see why one would be transmitted successfully and the other not.

RF links are notoriously poor at replicating NRZ data. I would expect that any wireless protocol is going to use another method of signaling.

 

So, for the sake of clarity....I am to understand that the various wireless systems (not lighting, but midi-audio) out there 'translate' the midi instruction in a midi pulse streams to some other instruction(s) which should perform the same function. And, in my case, it would appear, that my off-board sister module from the instrument manufacturer cannot interpret the translated instructions. And, the only solution would be for that manufacturer to change his design. There is no point to try different wireless systems (I have tried two). Is that what is meant?

And, though the pulses coming from both my controllers are very similar (but not identical), the wireless translates them differently?

 

Modern wireless devices are really amazing in what they accomplish, they do all this with some really fancy footwork under the hood.

(I personally HATE "wireless mania"- but that's another story)

Spread-spectrum, frequency hopping, fancy modulation schemes, etc, a far cry from simple FSK techniques of the past.
Most use modulation methods that encode more than one bit of information at a time, sending "symbols" that encode multiple bits.

https://en.wikipedia.org/wiki/Symbol_rate

This concept inherently crushes any semblance of the original bit timing.
So... the manufacturer is left to "regenerate" the intended protocol from the data that is recovered, and they often cannot reproduce the nuances.