Circuit to stretch short pulse but not long ones

[Back2Volts]

I am dealing with a pulse train that is an odd variation of one-wire.   The timings are 200us-LOW/1.8mS-HIGH or 1.8mS-LOW/200uS-HIGH.    I need to stretch the 200uS segments, both high and low, to something like 400us, but leave untouched the rest.   Input pulse is 5V logic.  Output will be consumed by 3.3.

It seems to me that somehow a mono-stable has to be in there with some additional stuff, but dealing with both high and log segments throws a wrench in there.   

Any ideas will be appreciated.   

[T3sl4co1l]

Think this old circuit did something like that...



Put it in SPICE and see?

As for a logic synthesis, no shame in using two timers, one for each polarity.  How closely matched do the pulses have to be?

Can also rephrase it as: a high pulse can only be 400 to 1600us.  As long as the input is periodic, that accomplishes the same thing.  (If it's intermittent, you'll have to specify what to do during long stretches of 1 or 0, regardless.)

Tim

[Back2Volts]

Think this old circuit did something like that...



Put it in SPICE and see?

No need...  I'll just go ahead and bread board it   

As for a logic synthesis, no shame in using two timers, one for each polarity.  How closely matched do the pulses have to be?

I see no problem in using two mono-stables.   I will probably need some gates to merge the original and the two stretched signals.   I am trying to find if there is a smart solution.

Can also rephrase it as: a high pulse can only be 400 to 1600us.  As long as the input is periodic, that accomplishes the same thing.  (If it's intermittent, you'll have to specify what to do during long stretches of 1 or 0, regardless.)

Tim

The timings are not critical.   There will be occasional pulse trains, with the line idle at high.   The desired output wave will have bits encoded in 2000uS, with 0 being 200us-low/1600us-high and 1 being the reverse, 1600us-low/400us-high.

[mikerj]

400us monostable triggered by rising edge of input, and then input and output of monostable OR'd together.

[Back2Volts]

400us monostable triggered by rising edge of input, and then input and output of monostable OR'd together.

Wouldn't you think I would also need another monostable on dropping edge and OR that one too?   One of the monostable outputs would have to be the negated one.

I wonder if I can just use use a mosfet or a BJT polarized with three diodes as the OR gate. 

[Zero999]

400us monostable triggered by rising edge of input, and then input and output of monostable OR'd together.

Wouldn't you think I would also need another monostable on dropping edge and OR that one too?   One of the monostable outputs would have to be the negated one.

I wonder if I can just use use a mosfet or a BJT polarized with three diodes as the OR gate.

Look at the circuit posted by T3sl4co1l again.

Going from left to right, top to bottom. The comparator senses the threshold of the incoming pulses and inverts them. The next tow NPN transistors form a monostable. The PNP transistor is connected both to the output of the comparator and monostable, via ORing diodes. The rest of the circuit is buffering and level shifting, presumably to drive a MOSFET.

[Caliaxy]

What's the level in between the train pulses?

[Back2Volts]

What's the level in between the train pulses?

Idle, between train pulses, is high. 

[Caliaxy]

But you said that the last transition is from 1.8 ms low to 200 us high, inferring that the level goes back to low (at the end of the 200 us period). Shouldn’t the initial and final idle states be the same?

[Back2Volts]

But you said that the last transition is from 1.8 ms low to 200 us high, inferring that the level goes back to low (at the end of the 200 us period). Shouldn’t the initial and final idle states be the same?

I will try to capture the signal with the logic analyzer, later this afternoon. 

[MarkL]

It certainly depends on your output requirements for delay and jitter, but is there a reason you wouldn't want to tackle this with your favorite low pin-count microcontroller?

If the timing requirements are lax enough, it could be done using timer peripherals, or even just pure software, in a single 3.3V powered chip with 5V tolerant inputs.

[Back2Volts]

It certainly depends on your output requirements for delay and jitter, but is there a reason you wouldn't want to tackle this with your favorite low pin-count microcontroller?

If the timing requirements are lax enough, it could be done using timer peripherals, or even just pure software, in a single 3.3V powered chip with 5V tolerant inputs.

This is the deal.    I am working on a home project, using an ESP32 running MicroPython.   I have to decode this pulse stream which is intercepted from an odd radio remote.   Because this is not one-wire, there is no driver available, so I have implemented a pin interrupt routine solution.   The problem is that due to the fact that MP on the ESP32 runs over FreeRTOS, there is a lot of ISR latency uncertainty, at times a bit over 200uS, causing corruption.

I have many options.   One is to move from Micropython to C, over FreeRTOS, but that makes developing the application rather hard.   Two is to drop the ESP32, go to something else, but then I have to use an external piece for WIFI, adding a layer of complexity and tediousness to the development.   There are few if any off the shelf boards with WIFI in the dimensions I need.   Third is to add an external micro to handle the decoding of the stream, not the stretching,  but again this adds a layer of complexity in the development, programing, etc..   Fourth, go to an STM32/WIFI MicroPython supported board.   There is such a piece of hardware, high quality, over $50, made in Europe, not available here.  I am exploring getting it, but things in the UK are not good right now.   That board run MicroPython on bare metal, and interrupt handling is supposed to be quick.

Bottom line is that I rather put the effort on the higher application layer, GUI over iPhone.       

[Back2Volts]

But you said that the last transition is from 1.8 ms low to 200 us high, inferring that the level goes back to low (at the end of the 200 us period). Shouldn’t the initial and final idle states be the same?

Just in case I can't get around to capture this later, think of the protocol as being, line idle high and 0/1  encoded by changing the length of a negative pulse.   The sending device builds each bit out of ten 200us units, dedicating either 1 or 9 units to the pulse, and padding accordingly with high up to ten units.   So information wise, the high is irrelevant, other that to determine end of transmission by holding the line high long enough.

Does that make sense?

[MarkL]

But you said that the last transition is from 1.8 ms low to 200 us high, inferring that the level goes back to low (at the end of the 200 us period). Shouldn’t the initial and final idle states be the same?

Just in case I can't get around to capture this later, think of the protocol as being, line idle high and 0/1  encoded by changing the length of a negative pulse.   The sending device builds each bit out of ten 200us units, dedicating either 1 or 9 units to the pulse, and padding accordingly with high up to ten units.   So information wise, the high is irrelevant, other that to determine end of transmission by holding the line high long enough.

Does that make sense?

I think so.

If I get it, it seems to me you might be able to use the UART to capture one protocol bit at a time and return the result in a byte.  You could treat the negative pulse transition as the start bit, and then capture 8 more time slots, and then a fake stop bit.

If you set the baud rate to 200us, you would get 00000000 if it was just a 200us negative pulse, or 11111111 if it was 1.8ms.  You're really using the UART to sample the input pin at a known rate.

The UART on the ESP32 appears to have a substantial FIFO, so you shouldn't lose any data by the time you can process the UART data.

The other idea was to set up the PWM peripheral to time the pulse transitions.

200us is a really long time for an IRQ response.  I also wonder if there's a way to increase the priority.  You'll have to excuse if that's an obvious thing; I'm not a ESP32 user.

[Back2Volts]

But you said that the last transition is from 1.8 ms low to 200 us high, inferring that the level goes back to low (at the end of the 200 us period). Shouldn’t the initial and final idle states be the same?

Just in case I can't get around to capture this later, think of the protocol as being, line idle high and 0/1  encoded by changing the length of a negative pulse.   The sending device builds each bit out of ten 200us units, dedicating either 1 or 9 units to the pulse, and padding accordingly with high up to ten units.   So information wise, the high is irrelevant, other that to determine end of transmission by holding the line high long enough.

Does that make sense?

I think so.

If I get it, it seems to me you might be able to use the UART to capture one protocol bit at a time and return the result in a byte.  You could treat the negative pulse transition as the start bit, and then capture 8 more time slots, and then a fake stop bit.

If you set the baud rate to 200us, you would get 00000000 if it was just a 200us negative pulse, or 11111111 if it was 1.8ms.  You're really using the UART to sample the input pin at a known rate.

The UART on the ESP32 appears to have a substantial FIFO, so you shouldn't lose any data by the time you can process the UART data.

The other idea was to set up the PWM peripheral to time the pulse transitions.

WOW!   If that works, it would really solve it.   I have to give it a try.   

200us is a really long time for an IRQ response.  I also wonder if there's a way to increase the priority.  You'll have to excuse if that's an obvious thing; I'm not a ESP32 user.

Yes.    What happens is that the MicroPython VM is running as a FreeRTOS task, and the way I understand it, the trip of the IRQ through the layers can cause very high latency.   Still, the ISR is processed interrupting the current user level in the VM, but still it is that bad.   There is no way to play with the interrupt priority, and as far as threading or tasking with different priorities under official Micropython, there are no such things.   The best it can be done is use something called UASYNC process coroutines, with no priorities.

AFAIK,  It is only the ESP32 implementation that has this latency problem.    I heard the STM32 one, on bare metal is very quick to respond, but again it is hard to get an small STM32/WIFI supported by Micropython.

FWIW, I did look into using a low pin count ATTINY85 to capture the pulses, but decided to avoid it.

Thanks     

[Back2Volts]

I can't believe it!   The TTGO-Display ESP32 module I have been using does not have externalized the two free UARTs 1/2.   I have checked another different TTGO module I have on hand and the same!

Fortunately, I have a third one, an Adafruit HUZZAH32 that has one of them on the on the pins.   I'll rwire the breadboard with it tomorrow, flash it and see if I can make it work.

[Back2Volts]

Looking at the ESP32 datasheet and the underlying UART driver source in MicroPython I figured out that the UART pins can be remapped, so I was able to use the TT-GO board.   If took me a while to make it work because I did not know some of the chip pins can only support imput, and I was getting errors when trying to create the UART object.   This project has been a very slow learning project...

Once past that, I have been able to test it and it works! 

Thank you MarkL !!!

[MarkL]

You're welcome - glad it worked for you!

[Back2Volts]

Just for kicks, although I do not have a need for the pulse stretcher any more, I have tried to put something on LTspice, but I am getting an error box with "Fatal Error: Multiple instances of Pin".   

It has been a long while since I have touched the simulator, and when I did I was never proficient at it.   May be one of you guys can take a look at it, but again, it is not something I need.   Just for learning.   I pulled the model from a forum reference.




 PulseStretcher.zip (3.15 kB - downloaded 36 times.)

[Back2Volts]

I have figured it out.   Commenting out the .inc fixed it.   Now to figure out what it does and does not do

[Back2Volts]

Just for fun, I put some time on the spice.   I had to replace the BJTs with MOSFETs.   I had to add two Schottky clamps to clip pretty bad overshoots.