Arduino Forum

Using Arduino => Sensors => Topic started by: WPD64 on Dec 13, 2018, 08:50 pm

Title: Timing microsecond pulses
Post by: WPD64 on Dec 13, 2018, 08:50 pm
Dear Arduino community

I have written a sketch to parse real-time manchester encoded data.

This type of encoding requires the timing of consecutive HIGH and LOW states.
I saw no way to use pulseIn() because it *consumes* the trailing edge which would be needed to time the following state.

So I implented my own timing function using analogRead() and micros().


In my recent efforts to port the code to the z-uno I stumbled over the fact that z-uno does not offer  micros().

Does anybody see any way to solve my problem?
EDIT: platform is the UNO.


Thanks so much
Sebastian


For reference here's my timing algorithm

Code: [Select]

unsigned long t0 = micros();
unsigned long t1 = t0;
  
int a = analogRead(pin);
 
while ((a >= sig_min) && (a <= sig_max) && ( t1-t0 < timeout)) {
    
    a  = analogRead(pin);
    t1 = micros();
}

return (t1-t0);

// sig_min and sig_max are margins to bracket noisy HIGH or LOW
// e.g. for LOW:    sig_min=0;    sig_max=400
//     for HIGH:    sig_min=400;  sig_max=32767
//
//

Title: Re: Timing microsecond pulses
Post by: AWOL on Dec 13, 2018, 09:50 pm
Why analogRead? it is very slow.
Title: Re: Timing microsecond pulses
Post by: MarkT on Dec 13, 2018, 10:27 pm
You need digitalRead for any digital encoding.

Is your signal not digital?

Or put another way please provide full details of all the hardware involved, so we don't have
to keep guessing and asking questions...
Title: Re: Timing microsecond pulses
Post by: WPD64 on Dec 13, 2018, 10:36 pm
I had trouble using digitalRead() because the signal from the RF module is quit noisy.

The thing is, my programm is working flawlessly in processing RF data from a bunch of 433Mhz thermometers.

However, after browsing the forum about manchester decoding I am beginning to think I took a very unelegant approach and should be looking into interupts.

----------------------------------

As to the setup:
I have started out with commercially available set of 8 thermometers and a display unit communicating at 433Mhz.

I took the receiver board from the display unit and connected it to a UNO input pin and began analyzing the incoming signals.
Title: Re: Timing microsecond pulses
Post by: MarkT on Dec 13, 2018, 10:42 pm
Full details of all the hardware - that means links to datasheets/product pages, etc.
Title: Re: Timing microsecond pulses
Post by: WPD64 on Dec 13, 2018, 10:51 pm
The details of the external hardware really are of no relevance here.
I have a manchester encoded signal on a UNO input pin [0...3.3V] which is somewhat noisy.

At the time of implemenation I considered the signal to not really be digital, so I chose to use analogRead() and do the digitization myself.


Title: Re: Timing microsecond pulses
Post by: AWOL on Dec 13, 2018, 10:58 pm
The details of the external hardware really are of no relevance here.
analogRead takes around 100 microseconds.
It's hard, in that case, to understand this thread's title.
Title: Re: Timing microsecond pulses
Post by: WPD64 on Dec 13, 2018, 11:02 pm
If I was beeing unclear I am very sorry.
Maybe I should start a new thread along the lines of...

I took the quite inefficient way of analyzing a stream of noisy manchester encoded data in a tight loop using analogRead()

I than detected rising and falling edges manually and was able to decode the signal.
However, is there any more elegant way of implementing this.

The incoming signal is ~0 for LOW and ~3.3V for HIGH
Title: Re: Timing microsecond pulses
Post by: WPD64 on Dec 13, 2018, 11:09 pm
analogRead takes around 100 microseconds.
It's hard, in that case, to understand this thread's title.
mmh, I am recording pulse widths of 500 +/- 30 us reliably.
title should maybe have been 'some 10 microseconds'

EDIT: or rather 'timing 500 us pulses'
Title: Re: Timing microsecond pulses
Post by: Wawa on Dec 13, 2018, 11:40 pm
I had trouble using digitalRead() because the signal from the RF module is quit noisy.

The thing is, my programm is working flawlessly in processing RF data from a bunch of 433Mhz thermometers.
Hash is normal on the data-slicer output of a 433Mhz receiver.

Everybody else is using a library for that.
I have used rs-switch (https://github.com/sui77/rc-switch), but there are others.
Leo..
Title: Re: Timing microsecond pulses
Post by: WPD64 on Dec 13, 2018, 11:49 pm
Hash is normal on the data-slicer output of a 433Mhz receiver.

'Hash' beeing noise ?
Sorry - I am not a native speaker
Title: Re: Timing microsecond pulses
Post by: Wawa on Dec 14, 2018, 01:12 am
Yes, simple 433Mhz OOK receivers output a full digital signal (noise) when nothing is received.
It's up to the software to detect if it contains a valid remote signal.
rc-switch uses pin2 of an Uno (interrupt#0).
The library comes with examples.
Leo..
Title: Re: Timing microsecond pulses
Post by: WPD64 on Dec 14, 2018, 08:59 am
Thanks Leo

Title: Re: Timing microsecond pulses
Post by: WPD64 on Dec 14, 2018, 09:19 am
Alas rc-switch uses micros() as well. So no use to me.

Title: Re: Timing microsecond pulses
Post by: ard_newbie on Dec 14, 2018, 09:38 am
I noticed that your actual platform is a UNO, however if you can't get what you want, an Arduino DUE has an USART peripheral with the Manchester encoding/decoding option in hardware, easy to use.
Title: Re: Timing microsecond pulses
Post by: WPD64 on Dec 17, 2018, 10:01 am
I noticed that your actual platform is a UNO, however if you can't get what you want, an Arduino DUE has an USART peripheral with the Manchester encoding/decoding option in hardware, easy to use.
Thanks for that information. I'll keep that in mind for my next hardware purchase.


To those of you wondering why I am not using a digital input and interrupts:
The signal is actually only 2.5V for HIGH.
Because I orgininally implemented the code several years ago I had forgotten all about that.

Anyway, I solved the original problem of porting from Arduino to z-uno by implementing serial communication bewtween the two and leaving the RF/manchester part on the Arduino.


Just for your information:
The z-uno environment and compiler are really not fit to implement any complex stuff.
There are many shortcomings particularly in c++, e.g.

no static members
no class inheritance
limited functionality in initialization lists, hence no member variables by reference

Plus, compiler errors hardly ever point you the the correct line of code which makes debugging a pain.

Cheers
Sebastian