high res timing values -> midi values

[Guest lanceblisters]

 I have several ultrasonic rangefinders (devices which measure distance by echolocation, emitting a click and timing the echo), and I wish to build a driver/midi convertor using mios.  I currently have a parallel-port driver which does the following:

 1) set the "reset" pin high

 2) set the "trigger" pin high  (causes rangefinder to play audible click)

 3) check the current time

 4) busy loop until "echo" pin goes high (when rangefinder detects echo)

 5) check the current time

 6) calculate distance to echo-producing object from time until echo and speed of sound.

 7) repeat 1)-6) for each additional rangefinder

 8) repeat

I want to support multiple rangefinders, and run them in parallel rather than serial.  I'll set all the trigger pins high, write the current time, busy loop checking "echo" pins one after the other.  When a pin goes high, I'll save the current time.  After the echo timeout value, I'll calculate the distances for each rangefinder.  If the distance has changed, I'll emit a midi message containing the raw time value, or map the range of times onto a cc controller or pitch bend.  Any problems with this approach?

Does anyone have example code to implement timing functionality, and to calculate the difference between time values in microseconds?  Is there an existing project which takes time measurements and creates MIDI messages in response?

 -geoff

[TK.]

Hi Geoff,

are we speaking about delays of some microseconds or miliseconds?

Best Regards, Thorsten.

[Guest lanceblisters]

Oops, I left a few lines out of my post:

Programming MIOS, how can I make time measurements with better than 1ms accuracy?

Will the pin sampling rate be fast enough?  I'm hoping for 100 microsecond time resolution, ideally 10 or less (as fast as possible

for the most accurate measurements.)

How to structure the timing loop?  The TIMER function has only 1ms resolution.  Can I do a busy loop?  Use TICK?

 -geoff

[TK.]

Hi Geoff,

the timer function has a resolution of 100 nS (nanoseconds!) ;-)

1 ms capturing cycle is used by the SRIO handler for the DIN and DOUT module, if a higher rate is required, then just program a USER_Timer routine and call it every 100 uS (microseconds) or so... In this case it's easier to connect the sensor signals directly to the PIC pins for best performance.

J5, J6, J7, the SO and RC pin of J10 and J14 (requires MIOS V1.5) can be used for this.

If these 15 IO pins are not enough, then you could control some serial shift registers from your routine.

Best Regards, Thorsten.

[Guest lanceblisters]

Alright, I'm starting to see how this will come together....

I'm new to MIOS and assembly programming, so there is

a lot to wrap my head around.

On startup, I'll set the timer to be called every 10 microseconds (about a tenth of an inch at the speed of sound, the practical physical resolution limit)

When I trigger the rangefinders by setting their "trigger" pins high, I will set my internal counter to zero, and the variables which will hold the rangefinder time values to zero.

Whenever my callback is triggered, I increment my internal counter.  For each rangefinder whose time value variable is zero, I check the voltage level on the rangefinder output pin.  If the voltage is high (echo detected) then I'll copy the value of my internal counter into the rangefinder's time value variable.  When the internal counter value has reached the maximum rangefinder timeout value (ten to thirty milliseconds, depending on the maximum distance I intend to measure) then I push the appropraite MIDI bytes onto the MIDITxBuffer, set the rangefinder "reset" pins high, and then set the "trigger" pins high and zero the variables as above.

Will the above work?  I'm aware that the UserTimer functions are interrupt driven, so it is important to limit the amount of work I do.  Can I push bytes onto the txBuffer, and set a couple pins high, within my usertimer function?  Or, should I do the MIDI packet building in a different context?

Thanks for your help.

 -geoff

[TK.]

Very good, I would also realize it that way.

But I wouldn't push the MIDI events into the Tx Buffer from an ISR. Although this works for debugging purposes, there are some cases which "hurt": a) the integrated MIDI merger could fail, b) the MIOS SysEx parser could fail, c) a deadlock scenario if the Tx Buffer is full and the Tx sender (which is also an ISR) cannot be executed since your own ISR blocks the execution (nested interrupts are not possible)

So, it's better to notify changes to a second routine which is called from USER_Tick - thats the common programming style which saves you from a lot of trouble. Example can be found in j5_din_v1_3.zip

Best Regards, Thorsten.