Electronic – Time to digital converter (TDC) for time of flight (TOF) applications. 66.6 picosecond sample

adcclock-speedRFvhf

My question is in regards to dynamic range of short time period TDCs, or alternative solutions to a time to digital application.

If further information is required, please ask.

TDC datasheet

Question.

TDC7200 datasheet says,
Measurement Range:
– Mode 1: 12 ns to 500 ns
– Mode 2: 250 ns to 8 ms

I wish to measure 66.6ps as my fastest sample and 3.33ns as my slowest sample.

Both mode 1 and 2 are outside of my desired range, however I see the datasheet also says 55ps resolution. Further down it also says LSB = 55ps.

Does this mean that if I wait for 12ns then all samples thereafter are within 55ps accuracy?

In other words:

fastest sample = 12ns
next sample = 12.055ns
next 12.11ns
next +55ps
etc etc until the nBit register is full?

Best Answer

Regarding

Does this mean that if I wait for 12ns then all samples thereafter are within 55ps accuracy. In other words. fastest sample = 12ns , next sample = 12.055ns

Actually the TDC7200 datashet specifies:

+-----------------+------------------------------+-----+-----+-----+------+  
|      Param      |         Description          | min | typ | max | unit |  
+-----------------+------------------------------+-----+-----+-----+------+  
| T1STARTSTOP_Min | t_min between Start and Stop |  12 |     |     | ns   |  
| T1STOPSTOP_Min  | t_min between 2 Stop Signals |  67 |     |     | ns   |  
+-----------------+------------------------------+-----+-----+-----+------+

table adapted from datasheet, formatted thanks to online tool

So if first sample is at 12ns then next sample cannot arrive before 12+67=79 ns.

Related Solutions

Electronic – Low-power wireless module strategy

I have open source and open hardware sensor that would give you a working starting point: it is internet connected and transmits its temperature, humidity, and battery voltage every two minutes an will last for 3-5 years on 2xAA batteries. It is based on the M12 6LoWPAN module.

I'll try my best to grab touch on all of your questions:

Regarding band tradeoff:

433MHz, 915MHz, 2.4GHz

Range vs. antenna size is the clear tradeoff here. Free-space path loss is a function of wavelength so lower frequencies travel much farther for the same attenuation. BUT, in order to capitalize on this you'll also need a suitable antenna which also scales with wavelength. The 2.4Ghz antenna on the M12 takes about 2 sq. cm of PCB area.

A second factor is licensing. 2.4GHz can have unlicensed stations worldwide. 915MHz is only unlicensed in US (it's a GSM band everywhere else). I'm not sure the restrictions on 433MHz.

Data rate is also effected by frequency choice according to Shannon–Hartley theorem; you can cram more data into a higher frequency band. This isn't always used for more final data rate though. 802.15.4, for instance, has 4 bits of redundancy for every real bit seen at the data layer. The 32 symbols are pseudo-orthogonal so you have to corrupt several low level bits to cause an error. This allows 802.15.4 to operate under the noise floor (research suggests at -5dB SNR) and makes it relatively robust to interference.

Now on to the next hard topic,

low-power radio operation:

Compared to household battery sources (e.g. AA alkalines), even the "low-power" SoCs such as the mc13224v aren't very low power. The transmitters are around 30mA at 2-3.5V and the receivers are 25mA or so. Without turning the radio off and putting the CPU to sleep, this load will drain 2 AAs in a few days. The high power consumption of the receiver is often surprising to people and probably the biggest pain in developing low power radio systems. The implication is that to run for years, you can almost never transmit or listen.

The goal to get "year long" operation from 2xAA alkalines is to get the average current of the system to be < 50uA. Doing so puts you at years and up against the secondary effects from the batteries such as self-discharge and the 7 year self life for household batteries.

The best way to get under <50uA average is if your transceiver doesn't need to receive. If this is true, then you can "chirp" the data as quickly as possible and put the system into a low power mode (say approx 10uA) for most of the time. The TH12, for instance, transmits for about 10ms, but there is other overhead in the system regarding processing time and setup times for the sensor involved. The details can be worked out with a current probe and spreadsheet:

Wake Current measurements

From that type of analysis you can work out what the run-life is going to be (assuming you have an accurate discharge curve for your battery).

If you do need to receive data on the low power side (e.g. to make a sleepy router in a mesh network) then the current state-of-the-art focuses on time division techniques. Some tightly synchronize the network, such as 802.15.4 beacons, and others use a "loose" system such as ContikiMAC (which can be easier to implement esp. if your hardware doesn't have a stable timebase).

Regardless, my experience shows that these methods are around 400uA average which puts you in the "months to maybe a year" run-time with 2xAAs.

Collisions:

My advice: don't worry about them for now. In other words do "aloha" (your option #1) where if you have data send it. If it collides then maybe resend it. (this depends on you goals). If you don't need to ensure that every sample is received then just try once and go to sleep right away.

You will find that the power consumption problem is so hard that the only solution will be a network that isn't transmitting much at all. If you just try, it will probably get through. If it doesn't, you can always try again later.

If you do need to make sure every datagram gets through then you will have to do some kind of ACK scheme. In the 6LoWPAN world, you can use TCP which will keep retrying until your battery is dead. There is also CoAP which uses UDP and has a retry mechanism (but doesn't promise delivery). But every choice here will impact run-time. If you are operating for years, the impact will be in months.

Your option #2 is built into 802.15.4 hardware as CCA. The idea is that receiver turns on for 8 symbols and returns true or false. Then you can make a decision about what to do next. You can play with these schemes all day/week. But every time you do something like this you shave more weeks off the run-time. That's why I suggest to start simple for now. It will work quite well if you are trying for long run-times.

Electronic – Stuck codes in samples from ADC

Interesting. I don't think I've ever seen this anomaly before.

It's often convenient to think of a SAR ADC as if it samples the input analog voltage at some instant in time. In practice, there is a narrow window of time where changes in the input analog voltage -- or noise on the analog voltage reference, or noise on the GND or other power pins of the ADC -- can affect the output digital value.

If the input voltage is slowly rising during that window, then the less-significant bits of the SAR output will be all-ones.

If the input voltage is slowly falling during that window, then the less-significant bits of the SAR output will be all-zeros.

A very narrow noise pulse at the "wrong" time during conversion can have a similar effect.

Right now my best guess is that you're using some sort of analog switches or op amps that don't work quite as well (higher resistance or something) near the high and low power rails as they do near mid-scale, somehow letting in one of the above kinds of noise, which causes the less-significant bits to be all-ones or all-zeros.

I've seen some sigma-delta ADCs and sigma-delta DACs that have good resolution at mid-scale, but worse resolution near the rails -- but the effect looks different than what you show.

The "plot of the difference between one sample and the next sample over the entire full scale range" is fascinating.

If I were you, I would make a similar plot that, instead making the X value the difference between one sample and the next, make the X value the least-significant 6 bits of the raw ADC output sample. That would quickly show if the "stuck" values are mostly lots of 1s in the least-significant bits (maybe input is slowly rising?) or lots of 0s in the least-significant bits (maybe input is slowly falling?).

I am sampling "pulsed" DC voltages. That means that for each measurement I put a voltage on the DAC, let it settle for at least 100 times it's settle time, then tell the ADC to convert - and when conversion is finished, I put the DAC back to 0 V.

My understanding is that when ADC manufacturers say "no missing codes", the test they use involves several capacitors adding up to a huge capacitance directly connected to the ADC input, and some system driving a large resistor connected to that capacitance that very slowly charged or discharged that capacitor, slowly enough that the ADC is expected to see exactly "the same" voltage (within 1/2 LSB) for several conversion cycles before it sees "the next" voltage (incremented by 1 going up, decremented by 1 going down).

If I were you, I would see if such a "continuous slope" test gives the same weird "stuck code" symptoms as the "pulsed test". Perhaps that would give more clues as to exactly what component(s) are causing this problem.

Please tell us if you ever figure out what caused these symptoms.