IR communication protocol/design for low latency/fast response - ideas?

[Corporate666]

I am working on an automation project that requires a sensor that communicates wirelessly.  There will be a receiver tied into the machine and a sensor located a meter or two away.  The sensor needs to be battery powered, but it only needs to detect during a short window of time.  But when it does detect, I need the receiver to trip as soon as possible.  I also need to be sure each receiver is only tripped by the sensor that's paired with it, and not stray light from the sensor on the adjacent machine.

I'm going to have two-way communication between sensor and receiver using IR, so the receiver will send a "start sensing now" signal to the sensor which will wake up. 

I I know there are various IR protocols out there, but the overhead of the modulated signal to transmit data, plus needing to receive enough packets of data to determine that the correct sensor tripped seems to mean a delay of tens of milliseconds if not more.  I'd like to reduce that latency and ideally be below a millisecond. 

I'd appreciate any comments/feedback on the approach to take here.  I'd like to use Cypress PSoC MCU's as I'm pretty invested in that ecosystem and very familiar with their programming - but I can do another route if there's something that would make all of this easier.

[ogden]

What you mean by "needs to detect during a short window of time" and "receiver is only tripped by the sensor that's paired with it". Are you building lap timer? If you can tell more about actual application - do it. Usually it helps.

You can build system using modulated IR. IRDA is outdated and most likely hard to get, yet you can use TV remote receivers. "start sensing now" could be just 0101010... pattern, after receiving number of 01010101... sensor can immediately transmit it's unique ID+checksum (16+16bits?), for defined number of times.

[ajb]

CNC touch probe?

IRDA supposedly goes up to 4Mbps, not sure how fast the built-in IRDA peripherals in MCUs can go.  Would that be fast enough?  Depending on the application you might want to go to a sort of negative detection method, where the sensor transmits a periodic signal so that the receiver knows it's okay and not tripped, then if the receiver misses a message it can assume that the sensor might have tripped.  If the timing information is really important, you could have the sensor's tripped message include a count of the number of messages sent since the trip event.  Then even if the receiver misses the first message for whatever reason, the count will tell it how many message intervals back the event occurred.

[Corporate666]

What you mean by "needs to detect during a short window of time" and "receiver is only tripped by the sensor that's paired with it". Are you building lap timer? If you can tell more about actual application - do it. Usually it helps.

You can build system using modulated IR. IRDA is outdated and most likely hard to get, yet you can use TV remote receivers. "start sensing now" could be just 0101010... pattern, after receiving number of 01010101... sensor can immediately transmit it's unique ID+checksum (16+16bits?), for defined number of times.

I don't want to get too much into the application, partly because I have an NDA and also don't want to re-invent the wheel in this thread   but basically a robot will move a part from A to B and needs to check the position of the part in-between as it's doing the move and corrects any misalignment prior to loading into B.  These transitions only happen when A is ready to transition to B... so I want the sensor to be in sleep mode and saving battery until the detection needs to happen. The receiver will transmit a wake-up to the sensor which will run until it detects, then go back to sleep.

The problem, AFAIK, with existing protocols is that they have a start-of-transmission signal, then the actual data.  1's and 0's are sent by modulating the IR beam ... so the start data plus address data of the sensor takes tens of milliseconds to go from sensor to receiver (or more?).  Some of this can be programmed out by estimating the motion that occurred during the lag time, and the motion of the robot can be slowed down so less travel occurs between sensor trip and receiver acknowledge... but I want to take out as much of that lag as possible.  There are fast IRDA transceivers (4Mbs) but they seem to mostly be obsolete/out of stock.  Was looking for the best way to do this... either using an off-the-shelf transceiver or discrete IR transmitter detectors in sensor and receiver.

[Corporate666]

CNC touch probe?

IRDA supposedly goes up to 4Mbps, not sure how fast the built-in IRDA peripherals in MCUs can go.  Would that be fast enough?  Depending on the application you might want to go to a sort of negative detection method, where the sensor transmits a periodic signal so that the receiver knows it's okay and not tripped, then if the receiver misses a message it can assume that the sensor might have tripped.  If the timing information is really important, you could have the sensor's tripped message include a count of the number of messages sent since the trip event.  Then even if the receiver misses the first message for whatever reason, the count will tell it how many message intervals back the event occurred.

Very close - checking position of a picked-up part on a robot loader before placing part in a fixture.   I have been looking at 4Mbps IRDA transceivers but it looks like they are going the way of the dodo... I wouldn't want to design something in that I can't get in the future.  I only checked Digikey but they have one 4Mbps unit in stock and it's marked obsolete.  I'll never need millions of these and always try to design in parts that I can get from multiple sources with low quantity requirements and other parts I could substitute in.

Definitely want to do negative detection for safety.. one of the main reasons the receiver will turn on the transmitter... so that it's always transmitting and stops upon detection.  But still need a fast, low-latency "ping" from the sensor to receiver that lets the receiver acknowledge a detection as quick as possible.

[ogden]

I don't want to get too much into the application, partly because I have an NDA

Sure. No worries. We will provide free solution for your well-paid job

The problem, AFAIK, with existing protocols is that they have a start-of-transmission signal, then the actual data.  1's and 0's are sent by modulating the IR beam ...

What you want - good SNR or low latency? Can't have both. To identify sensor ID and it's transmission reliably, single bit is not enough. Kinda obvious. The more bits you send - the longer time it takes to send/receive them.

so the start data plus address data of the sensor takes tens of milliseconds to go from sensor to receiver (or more?).

At fast enough bitrate it (single "ping") does not take too much time. Supposedly your TX and RX clocks are run from crystal oscillator so you can use short preambles. With 10 bit preamble and 16+16 bits of ID+CRC = 42 bits at 1Mbps takes 42 microseconds.

[soldar]

Similar recent thread: https://www.eevblog.com/forum/projects/short-range-(ltcm)-full-duplex-ir-data-exhange/

[Kjelt]

The reason it takes a few ms is for the AGC of the receiver to wake up and settle.
If the time window you need to sent data is limited you could continuously transmit in that period.
Also take a look at the techniques of safety emergency stop ir light fences.

[Buriedcode]

The reason it takes a few ms is for the AGC of the receiver to wake up and settle.
If the time window you need to sent data is limited you could continuously transmit in that period.
Also take a look at the techniques of safety emergency stop ir light fences.

Agreed.  If the receiver knows when the sensor is going to send data - because it is the thing that tells it to start sensing - then the time it takes to set up the sensor can be used to train AGCs and PLLs in preparation for the sensors signal.  Whilst you've mentioned "data" as in, sending numbers, you could just use PWM, with each sensor having a different carrier.  That way the sensor starts sending a signal continuously, and the information you wish to send is embedded in this, in this case the duty cycle.  The latency will be the period of the PWM + any computation required to convert that to meaningful data.

The accuracy will depend on the demodulator (analogue) but things like turn on/off times will generally be fixed and so could be used to offset the PWM measurement.  Of course, you could just used off-the-shelf IR recievers and a standard like NEC to continuously transmit bits.  Either way, the initial "settle" time is out of the way before the sensor has to send something meaningful. 

[pwlps]

If the receiver knows when the sensor is going to send data - because it is the thing that tells it to start sensing - then the time it takes to set up the sensor can be used to train AGCs and PLLs in preparation for the sensors signal. 

To minimize latency I would suggest to use a differential modulation scheme where no clock synchronisation is needed.  For example see:  https://www.tutorialspoint.com/digital_communication/digital_communication_differential_phase_shift_keying.htm

Here no Costas-loop and no PLL in the demodulator. Processing of I/Q signals can also be done digitally if your MCU has a fast ADC.

Edit: I also found this paper but didn't study it: https://pdfs.semanticscholar.org/c97a/27f9f11ba02cf82616e278848e849c3cb25c.pdf

[max_torque]

I don't want to get too much into the application, partly because I have an NDA and also don't want to re-invent the wheel in this thread   but basically a robot will move a part from A to B and needs to check the position of the part in-between as it's doing the move and corrects any misalignment prior to loading into B.  These transitions only happen when A is ready to transition to B... so I want the sensor to be in sleep mode and saving battery until the detection needs to happen. The receiver will transmit a wake-up to the sensor which will run until it detects, then go back to sleep.

To me this sounds rather like the old "if i knew i was going there, i wouldn't have started here" type effect!

If you have  robot doing a task, is it not much more preferential to have it do it's task accurately and in a timely fashion than rely on correcting it's mistakes via some sort of external system?

If i were designing a robot  "to move a part from A to B" i'd make sure that's exactly what it did, and not allow it to swerve off to "C" half way across......   

[ajb]

To me this sounds rather like the old "if i knew i was going there, i wouldn't have started here" type effect!

If you have  robot doing a task, is it not much more preferential to have it do it's task accurately and in a timely fashion than rely on correcting it's mistakes via some sort of external system?

If i were designing a robot  "to move a part from A to B" i'd make sure that's exactly what it did, and not allow it to swerve off to "C" half way across......   

Meh, there are lots of situations where it makes a lot more sense to correct for misalignments than to try to prevent them in the first place.  Think about a pick-and-place machine: It's impossible/impractical to package components in tape such that their alignment is guaranteed to the level required for accurate placement, so it's a lot more sensible to just measure the position of the part on the nozzle and then correct.  There's a similar problem with using robots to load/unload mechanical parts from machines: if the part has to sit in a staging area between steps, or worse, get put into a tote and moved to another cell, then you need to incorporate features to very accurately locate the part within that storage or transport system.  Or maybe the tolerance bands on the part itself are too large to accurately locate it mechanically, such as with a raw (metal) casting.  This is a common problem in the CNC machining world, which has to deal with issues of fixture repeatability, raw material tolerances, tool wear, etc, and so has widely adopted electronic probing as a way of measuring and compensating for all sorts of accuracy issues that are impractical (too expensive) to correct any other way.

[pwlps]

Here I will comment on my own answer (I find the problem interesting )

To minimize latency I would suggest to use a differential modulation scheme where no clock synchronisation is needed.  For example see:  https://www.tutorialspoint.com/digital_communication/digital_communication_differential_phase_shift_keying.htm

The schematics of the DPSK demodulator shown in https://www.tutorialspoint.com/digital_communication/digital_communication_differential_phase_shift_keying.htm
seems incomplete because there is no bandpass filter around the carrier, in real world I suppose what is labeled "DPSK signal" should be an IF (hetorodyned) signal.

But there is another similar differential scheme that does not need any heterodyne stage and that should theoretically have a similar performance : a differential QPSK (DQPSK),  here the phase jumps can be detected by the software so that the analog part of the circuit could only need two chips: a local oscillator and a QPSK demodulator. With the high dynamic range (12 bit,  >1MSPS) of  SAR ADCs of recent Cypress MCUs the analog AGC could be dropped too to optimize latency. Disclaimer: these are only my thoughts based totally on intuitive grounds, I never tested such a circuit.

[ogden]

But there is another similar differential scheme that does not need any heterodyne stage and that should theoretically have a similar performance : a differential QPSK (DQPSK),

Two incorrect statements
Heterodyne presence or absence have nothing to do with (de)modulation.
Differential or not, QPSK (4 phase angle encoding, 2 bits/symbol) do not have similar performance to BPSK (2 phase angles, 1 bit/symbol).
You shall update your knowledge ASAP. Start here: https://en.wikipedia.org/wiki/Phase-shift_keying

[pwlps]

But there is another similar differential scheme that does not need any heterodyne stage and that should theoretically have a similar performance : a differential QPSK (DQPSK),

Two incorrect statements
Heterodyne presence or absence have nothing to do with (de)modulation.
Differential or not, QPSK (4 phase angle encoding, 2 bits/symbol) do not have similar performance to BPSK (2 phase angles, 1 bit/symbol).
You shall update your knowledge ASAP. Start here: https://en.wikipedia.org/wiki/Phase-shift_keying

Ok thanks for correcting me. I understand very well all the underlying maths and don't need your explanations, but sorry if my own explanation or wording was not precise.

Heterodyne presence or absence have nothing to do with (de)modulation.

It has a lot,  at least from the signal analysis point of view.

I don't want to go further in this kind of discussion, I give here a physicist' way of thinking, and you have an EE point of view, but you won't get any point attacking me on that.  Please take it easy and focus on electronics.

[ogden]

I don't want to go further in this kind of discussion

Good idea indeed.

[max_torque]

It is possible you are missing the point of my (rather flippant) post!

My point was that when you get "stuck" with some problem, it makes a lot of sense to take a step back and think about the best route forwards.  Now that may be to "fix" the problem come-what-may, but it also very often is to realise that your problem is in fact a symptom of some artifact that is entirely due to the way you originally approached the problem!

 

[pwlps]

So is this thread dead?  I would be interested in the OP development based on this discussion.
Basically I would repeat my thoughts: 1)QPSK is preferred over BPSK because carrier alignement is not necessary, 2) LO-based detection is preferred over synchronous detection because there is no need for heterodyning or passband.  All this is indeed very short and pithy and rereading my own posts I admit my writing is quite behind my thoughts ! (and has earned me some critics from Professor Ogden ), but I can explain it further on demand.

[ogden]

Basically I would repeat my thoughts: 1)QPSK is preferred over BPSK because carrier alignement is not necessary,

BS. Both requires carrier frequency alignment. QPSK needs better alignment than BPSK. - Compare BPSK/QPSK constellations and consider which one needs better phase angle precision.

2) LO-based detection is preferred over synchronous detection because there is no need for heterodyning or passband.

LO-based detector is nothing more than demodulator with built-in digital downconverter. Heterodyne is digital, but still there.

In fact phase modulation is bad choice for IR transmission. None of IRDA modes uses used phase modulation. Even fastest 0.5Gbps / 1Gbps mode developed used 2ASK/4ASK. Slower modes used just various pulse amplitude modulations (mostly RZ/NRZ/RZI/NRZI).

[pwlps]

BS. Both requires carrier frequency alignment. QPSK needs better alignment than BPSK. - Compare BPSK/QPSK constellations and consider which one needs better phase angle precision.

Again my loose wording. Talking QPSK I had in mind the demodulation technique whatever the actual number of points in the constellation.  The main point is here we need low-latency therefore a non-coherent or differentially coherent demodulation will be preferred over the standard carrier recovery techniques. The quadrature demodulator (called qpsk demodulator in the literature but it will do as well with a two-point constellation) is interesting because the decision rules can be implemented in software making it a natural choice for differentially coded signals, this is precisely the technique used in the article I cited.  This is just simpler than a bpsk synchronous demodulator (which is more delicate to implement), even though in theory  both should have a similar SNR (actually both loose about 3dB compared to demodulation with PLL-based carrier-recovery).  I'm not just talking general principles here, I try to figure out the practical implementation of the whole thing to see which scheme would be the simplest and most robust at comparable SNR/BER, and from this point of view a QPSK demodulator has some advantages. If you were thinking this way instead of just searching where to put your 'BS' marks in my text (but I don't mind) you would probably come to similar conclusions.

LO-based detector is nothing more than demodulator with built-in digital downconverter. Heterodyne is digital, but still there.

Nothing to do with digital vs analog issues, no need for any digital parts in heterodyne.

In fact phase modulation is bad choice for IR transmission. None of IRDA modes uses used phase modulation. Even fastest 0.5Gbps / 1Gbps mode developed used 2ASK/4ASK. Slower modes used just various pulse amplitude modulations (mostly RZ/NRZ/RZI/NRZI).

There is no ASK vs PSK issue in fast IrDA since it uses a baseband PPM coding without any carrier. This is sufficient for a point-and-shoot communication, here however the initial OP requirement was to be able to define independent frequency channels and the whole discussion begun from that point.  Actually in IrDA multiple channels can be defined too, but only at the IRLAP/IrLMP protocol level (sort of CDMA but I don't know the details).

[ogden]

Again my loose wording. Talking QPSK I had in mind the demodulation technique whatever the actual number of points in the constellation.

It's "terms all over the place", not loose wording.

Quadrature phase-shift keying (QPSK)
Sometimes this is known as quadriphase PSK, 4-PSK, or 4-QAM. (Although the root concepts of QPSK and 4-QAM are different, the resulting modulated radio waves are exactly the same.) QPSK uses four points on the constellation diagram, equispaced around a circle. With four phases, QPSK can encode two bits per symbol

There is no ASK vs PSK issue in fast IrDA since it uses a baseband PPM coding without any carrier.

Sure. Do you know why? - Because using IR LED you can't modulate phase or frequency of the light, only amplitude!

[pwlps]

Quadrature phase-shift keying (QPSK)
Sometimes this is known as quadriphase PSK, 4-PSK, or 4-QAM. (Although the root concepts of QPSK and 4-QAM are different, the resulting modulated radio waves are exactly the same.) QPSK uses four points on the constellation diagram, equispaced around a circle. With four phases, QPSK can encode two bits per symbol

And so what? There is nothing here in contradiction with what I say.

Sure. Do you know why? - Because using IR LED you can't modulate phase or frequency of the light, only amplitude!

Now I should be the one to mark a 'BS' (and a big one ).   Of course you can, it seems you are completely confusing light frequency (I'm not talking about this) and carrier frequency.  IrDA doesn't use carrier but other IR (or any light) applications can use it, e.g. in the so called multiple frequency phase-shift technique used by laser rangefinders. 

[ogden]

it seems you are completely confusing light frequency (I'm not talking about this) and carrier frequency.

Confusement is fully yours 

Quiz: What do you think is carrier in case of laser rangefinder? - Sound waves, radio waves or light waves?

[pwlps]

Quiz: What do you think is carrier in case of laser rangefinder? - Sound waves, radio waves or light waves?

Light wave is not really carrier because we don't use it's phase information (except in interferometric devices, but we weren't  talking about this).  Laser rangefinders use carrier frequencies in the range of tens of MHz.  Call it subcarrier if you want, I will not argue on terminology.

[ogden]

Light wave is not really carrier because we don't use it's phase information (except in interferometric devices, but we weren't  talking about this).

Right. - That's because using IR LED you can't modulate phase or frequency of the light anyway, only amplitude. Wait.... Didn't I say it before? Whatever are your terminology, IRDA association did not pick phase modulation but PPM instead for a good reason. I did say that as well. No need to reinvent the wheel - just take what is already developed.