After reading the latest posts I think I'm going to order a supply of H11L1 IC's...and an equal supply of sockets.
@jmg, please tell me more about "...encode the information as Servo-style pulse width. The Prop can generate and capture very precisely in time - much better than ADC precision."
Are you saying I could eliminate an ADC in reading the position of a joystick?
After reading the latest posts I think I'm going to order a supply of H11L1 IC's...and an equal supply of sockets.
@jmg, please tell me more about "...encode the information as Servo-style pulse width. The Prop can generate and capture very precisely in time - much better than ADC precision."
Are you saying I could eliminate an ADC in reading the position of a joystick?
That depends on the sensor, the very cheapest pot, needs a ADC, but many 'better' sensors can encode other outputs.
The Parallax servo here https://www.parallax.com/product/900-00360
includes a duty cycle encoded rotation feedback.
If reading a remote joystick position from a distance or you want to avoid the ADC conversion and transmit time, maybe look into the LM331 VFC. Then you would need only count the pulses/period and convert in software. I got the chips for around $3.00 from TI, noted amazon has a built module for 0-10v to 0-10khz for $6.00
@lardom - post your specs, the inputs and outputs you want, and what you want to do, what it could do, and what it must do. I'm sure we could offer quite a few suggestions. As for H11L1 optos they always need a good strong pull-up resistor for speed as even though the datasheet shows a 270R to 5V and says that the resistor value "doesn't matter much", well that's not true because those open-collector outputs must drive something and there's always capacitance involved. If I use optos I favor push-pull outputs that don't need resistors that consume more power than the rest of the circuit. For isolation I also use solid-state isolators, especially because they are capable of very high speeds, but mostly I just design the circuit in such a way that it doesn't need isolation.
However, another isolation method I use for multiple inputs/outputs is to have a dedicated micro to handle the signals and communicate serially over a tiny 8-pin bidirectional solid-state isolator such as the ADuM3211ARZ. In these situations I supply isolated power via a small 4-pin isolated DC-DC converter. That way you can have all those nasty voltages and currents completely decoupled from the Prop and its power.
@Peter Jakacki, I'm sorry it took so long to post. I've been experimenting with 38K and studying results on the scope. In my last oscilloscope test I flashed a TV remote at the receiver and the pattern was consistent. I still haven't gotten consistent responses from pulses that I sent with my code.
I admit, sometimes I'm a bit slow intellectually: There is OBEX code that I have resisted studying because I thought I could simplify it.
The idea is that the transmitter sends a stream of bytes, with a start bit, to the receiver. I based the pulse sizes on the SONY remote. I wrote a loop to see how fast the bytes would count up. (cog to cog)
It was fast enough so I thought that an IR joystick was possible.
I want to create 'version 2' of a wireless, mobile robotic arm with pan/tilt for a camera. I want 12V DC motors for the wheels and larger servos for the robotic arm. My first controller had two joysticks and three toggle switches. The 2nd version will have a single joystick for control of the wheels. For the arm and pan/tilt I want a controller that mirrors the position of the arm. Of course, the other big thing is that I have to protect the logic circuit.
I think a mobile arm with FPV could be a useful machine.
@lardom - it's a bit late now and I've got an early start so I will digest this info a little later. In the meantime here is a snippet of code for an NEC IR transmit where the codes are 32-bits.
3 := irled
pub IRTX ( code -- )
irled APIN irled LOW
38 KHZ 9 ms MUTE 4500 us
32 FOR 1 ROL 38 KHZ 450 us MUTE 450 us DUP 1 AND IF 450 us THEN NEXT DROP
9 ms
;
... I've been experimenting with 38K and studying results on the scope. In my last oscilloscope test I flashed a TV remote at the receiver and the pattern was consistent. I still haven't gotten consistent responses from pulses that I sent with my code.
An alternative is to use a Learning Remote approach. This can either learn at the 38kHz rate, or have fixed modulation, and learn at the data rate.
Edge locations are stored, and played back.
It was fast enough so I thought that an IR joystick was possible.
Do you mean via some existing receiver software, or do you want to send your own code, to a local IR receiver module on your PCB, and you code the Rx-demoulate too ?
An alternative is to use a Learning Remote approach. This can either learn at the 38kHz rate, or have fixed modulation, and learn at the data rate.
Edge locations are stored, and played back.
Do you mean via some existing receiver software, or do you want to send your own code, to a local IR receiver module on your PCB, and you code the Rx-demoulate too ?
Here's how I did it with the nRF24L01: I would send the first byte which identified the i/o pins I wanted to control. The first byte also cleared the variable array. For example I would send a %16 for the wheels followed by four bytes, one for each i/o pin. In this case when the incrementing variable "idx" equaled 4 those values would be passed to the motor driver. The toggle switches sent the first byte.
The stream of data was reasonably fast so latency was negligible in my view.
The challenge I want to tackle is that if I can find a way to send data at the same rate that I did with the nRF24L01 I can do the same thing with IR.
The challenge I want to tackle is that if I can find a way to send data at the same rate that I did with the nRF24L01 I can do the same thing with IR.
The IR receivers have quite modest speeds. Those with carrier detectors have the best range (20~40m claims), but spec's are usually for 600us / 600us bursts, and Rx decode is +/- 150us on the 600us in.
So that's just over 1k baud, plus some like pauses for their AGC schemes, or expect bi-phase, which drops data speeds by half.
The other class of IR receivers, target code learning, and have have shorter ranges (~ 5m), but higher bandwidth, and can reproduce the carrier signals. An example is TSMP77000
If 5m is enough range, you could try the faster versions ?
@jmg, I think you may have saved me from a big waste of time. Range is not a big issue for me. Latency, or response time, is.
I would have posted my nRF24L01 code to the OBEX but I'm not happy with it and I clearly had problems with the circuit.
As a hobbyist I find the challenges irresistible and fun. Contributing something of value to the OBEX is one of the only ways I know to say thank you to everybody who has helped me along the way. I really do appreciate it.
I have used IR for 9600 baud coms in some vending machine projects. But what I would have would be some LEDs on the front panel including an IR LED. I would use that both for transmitting shortrange baseband and also for receiving. For the host end I would pump the IR LED with plenty of current but I could operate over a few metres. The IR LED would even talk to an HP portable printer so reports could be gathered easily. Maybe baseband is a way to go. You can always use tubing to tighten up the pickup to help cutout external sources.
BTW, you can use any LED as a receiver but match the LED to the wavelength, so use an IR LED as an IR receiver. This is also a Q&D method for reading IR signals into a scope, just connect an LED to the probes!
Looks like the skews improved from
old: tpi - 5/f0 < tpo < tpi + 6/f0
to
new : tpi - 3.5/f0 < tpo < tpi + 3.5/f0
& because things are carrier (f0 ) relative, the 56kHz modules would be expected to give slightly better throughput than 38kHz.
It may be that experimenting with the number of stop bits can hit a sweet spot too, or a base64 encoder variant approach could shuffle the duty cycles to trade off some speed for better AGC match ?
For shorter ranges again, there are IrDA links. Those can manage 1m at 115200 baud.
I made a short clip showing a test of the code counting up. It's fast enough for my project but I can speed it up a bit if necessary. It's not a total waste of effort because I can still use it to pass data to a second Propeller.
Larry, if you were to modify your code so it's only reporting packets per second you might find you have a faster transfer rate. The serial terminal output can be quite cycle consuming.
Larry, if you were to modify your code so it's only reporting packets per second you might find you have a faster transfer rate. The serial terminal output can be quite cycle consuming.
-Mike R.
You are correct. I had to insert a pause, waitcnt(clkfreq / 950 + cnt), between each data packet to allow time for the terminal to display the values.
A pause between packets is always necessary because in my project each byte is passed to three cogs representing three modes of operation.
I used a similar data stream to program a mobile robotic arm with pan/tilt. The stream was fast enough that latency was not an issue for me.
I made a short clip showing a test of the code counting up. It's fast enough for my project but I can speed it up a bit if necessary. It's not a total waste of effort because I can still use it to pass data to a second Propeller.
If you want to experiment with faster speeds, and you have control of both ends, you could look into either
SENT (Single Edge Nibble Transmission) SENT_protocol
That uses a calibrate pulse, and then pulse-width encodes 4 bits into 16 time widths, repeating.
or
IrDA encode - that sends a narrow LED pulse for every TX_LOW on UART, and then monostable-stretches the pulse on receive side. (T=bit-time)
"I really think I should start using optocouplers in my designs.
Coincidentally, you may have here a solution to two problems. I've gotten a lot of mileage out of driving the anode of a suitably specified optocoupler's anode with a 38kHz signal from a Prop counter, and the cathode with whatever data I wanted to send. The photo transistor side of the optocoupler is then used to drive a whole stack of serially-connected IR LEDs suppied by a suitably high voltage.
The resulting IR flashes have tremendous range. Thanks to reflections and whatnot, they saturate a space, making orientation of the receiver not terribly important. Optocouplers aren't terribly fast, but the ones I use are perfect for 38kHz. Anything faster would be pointless.
Edit: "Suitably specified" in this case means a cheapie 4N35 from eBay. 4N33 is NOT okay. You do not want a photodarlington output. It's too slow even though it has great current gain. Something around unity current gain is all you want or need.
@jmg and @K2 Thanks for the ideas. I'm starting to get the sense that IR is actually worth the effort after all.
I don't want to open another can of worms because I'm not ready yet but I keep dreaming of a machine that can be controlled over the internet. My attitude is with a router and an IP "Why not". That's a subject for another thread.
Please help again! I have gotten a servo to rotate CW and CCW using IR. I connected the servo to pin 7 through an opto-isolator.
The problem is I timed it twice and both times it took 54 seconds before I saw a pulse from pin 7. I don't know where I screwed up so I decided to post what I've done so far.
54 seconds is a magic clue. It is just about as long as it takes for cnt to cycle completely at 80 MHz. I'm thinking you have a waitcnt that isn't initialized properly.
@tomcrawford, thanks. All the waitcnts were initialized but that made me realize something was 'not' initialized. Everything worked fine until I called the last child object and then I found the problem:
PUB MoveMotor(Pin)
dira[Pin]~~
repeat while position == 0 '<--- I HAD TO INITIALIZE THIS VARIABLE
repeat
outa[Pin]~~ 'go high
waitcnt(position+cnt) 'pulse width
outa[Pin]~ 'go low
waitcnt(clkfreq/50+cnt) 'wait for next cycle
Comments
@jmg, please tell me more about "...encode the information as Servo-style pulse width. The Prop can generate and capture very precisely in time - much better than ADC precision."
Are you saying I could eliminate an ADC in reading the position of a joystick?
That depends on the sensor, the very cheapest pot, needs a ADC, but many 'better' sensors can encode other outputs.
The Parallax servo here https://www.parallax.com/product/900-00360
includes a duty cycle encoded rotation feedback.
Other Rotational Sensor parts like https://www.idt.com/document/dst/zmid520x-datasheet
can output Analog/PWM or SENT (Single Edge Nibble Transmission)
However, another isolation method I use for multiple inputs/outputs is to have a dedicated micro to handle the signals and communicate serially over a tiny 8-pin bidirectional solid-state isolator such as the ADuM3211ARZ. In these situations I supply isolated power via a small 4-pin isolated DC-DC converter. That way you can have all those nasty voltages and currents completely decoupled from the Prop and its power.
I admit, sometimes I'm a bit slow intellectually: There is OBEX code that I have resisted studying because I thought I could simplify it.
The idea is that the transmitter sends a stream of bytes, with a start bit, to the receiver. I based the pulse sizes on the SONY remote. I wrote a loop to see how fast the bytes would count up. (cog to cog)
It was fast enough so I thought that an IR joystick was possible.
I want to create 'version 2' of a wireless, mobile robotic arm with pan/tilt for a camera. I want 12V DC motors for the wheels and larger servos for the robotic arm. My first controller had two joysticks and three toggle switches. The 2nd version will have a single joystick for control of the wheels. For the arm and pan/tilt I want a controller that mirrors the position of the arm. Of course, the other big thing is that I have to protect the logic circuit.
I think a mobile arm with FPV could be a useful machine.
An alternative is to use a Learning Remote approach. This can either learn at the 38kHz rate, or have fixed modulation, and learn at the data rate.
Edge locations are stored, and played back.
Do you mean via some existing receiver software, or do you want to send your own code, to a local IR receiver module on your PCB, and you code the Rx-demoulate too ?
Here's how I did it with the nRF24L01: I would send the first byte which identified the i/o pins I wanted to control. The first byte also cleared the variable array. For example I would send a %16 for the wheels followed by four bytes, one for each i/o pin. In this case when the incrementing variable "idx" equaled 4 those values would be passed to the motor driver. The toggle switches sent the first byte.
The stream of data was reasonably fast so latency was negligible in my view.
The challenge I want to tackle is that if I can find a way to send data at the same rate that I did with the nRF24L01 I can do the same thing with IR.
The IR receivers have quite modest speeds. Those with carrier detectors have the best range (20~40m claims), but spec's are usually for 600us / 600us bursts, and Rx decode is +/- 150us on the 600us in.
So that's just over 1k baud, plus some like pauses for their AGC schemes, or expect bi-phase, which drops data speeds by half.
The other class of IR receivers, target code learning, and have have shorter ranges (~ 5m), but higher bandwidth, and can reproduce the carrier signals. An example is TSMP77000
If 5m is enough range, you could try the faster versions ?
I would have posted my nRF24L01 code to the OBEX but I'm not happy with it and I clearly had problems with the circuit.
As a hobbyist I find the challenges irresistible and fun. Contributing something of value to the OBEX is one of the only ways I know to say thank you to everybody who has helped me along the way. I really do appreciate it.
BTW, you can use any LED as a receiver but match the LED to the wavelength, so use an IR LED as an IR receiver. This is also a Q&D method for reading IR signals into a scope, just connect an LED to the probes!
There is more info on serial links via remove AGC models here in a 2014 doc
https://www.vishay.com/docs/82666/tsdpreceiver.pdf
and they talk about an improved series here in 2018 (looks like mostly better Wi-fi tolerance, & less skews )
http://www.vishay.com/whatsnew/doc/npi_180309-NPI-TSOP131..etal.pdf
which might improve either the baud speed or error rates since that 2014 doc.
Looks like the skews improved from
old: tpi - 5/f0 < tpo < tpi + 6/f0
to
new : tpi - 3.5/f0 < tpo < tpi + 3.5/f0
& because things are carrier (f0 ) relative, the 56kHz modules would be expected to give slightly better throughput than 38kHz.
It may be that experimenting with the number of stop bits can hit a sweet spot too, or a base64 encoder variant approach could shuffle the duty cycles to trade off some speed for better AGC match ?
For shorter ranges again, there are IrDA links. Those can manage 1m at 115200 baud.
-Mike R.
You are correct. I had to insert a pause, waitcnt(clkfreq / 950 + cnt), between each data packet to allow time for the terminal to display the values.
A pause between packets is always necessary because in my project each byte is passed to three cogs representing three modes of operation.
I used a similar data stream to program a mobile robotic arm with pan/tilt. The stream was fast enough that latency was not an issue for me.
SENT (Single Edge Nibble Transmission) SENT_protocol
That uses a calibrate pulse, and then pulse-width encodes 4 bits into 16 time widths, repeating.
or
IrDA encode - that sends a narrow LED pulse for every TX_LOW on UART, and then monostable-stretches the pulse on receive side. (T=bit-time)
I don't want to open another can of worms because I'm not ready yet but I keep dreaming of a machine that can be controlled over the internet. My attitude is with a router and an IP "Why not". That's a subject for another thread.
The problem is I timed it twice and both times it took 54 seconds before I saw a pulse from pin 7. I don't know where I screwed up so I decided to post what I've done so far.
PUB MoveMotor(Pin) dira[Pin]~~ repeat while position == 0 '<--- I HAD TO INITIALIZE THIS VARIABLE repeat outa[Pin]~~ 'go high waitcnt(position+cnt) 'pulse width outa[Pin]~ 'go low waitcnt(clkfreq/50+cnt) 'wait for next cycle