LoRa – does CAD work at weak signal levels ?

The SX127x data sheet defines CAD as;

When in CAD mode, the device will check a given channel to detect LoRa preamble signal

And;

Principle of Operation

The channel activity detection mode is designed to detect a LoRa preamble on the radio channel with the best possible power efficiency. Once in CAD mode, the SX1276/77/78/79 will perform a very quick scan of the band to detect a LoRa packet preamble.

There is little to suggest that CAD works on the body of the packet, which in practice is the major par of the transmit time. So whilst CAD is supposed to detect the pre-amble of a packet, does it detect a packet at other times ?

To test this the idea would be to transmit long packets (of several seconds) and have a receiver constantly running the CAD process. When each CAD period was finished the CAD detected flag would be read and a LED turned on or logic level set if the flag was active. Thus by observing the LED so that you could see for how long a packet was detected by CAD and how consistent the detect was.

The packets would be sent in sequence of descending powers (17dBm down to 2dBm) so it would be possible to see by observing the LED how well CAD performs as the signals got weaker. The link test software I use was changed to send packets that were close to 5 seconds long at SF12 and bandwidth 125khz.

The test transmitter was fitted with an SMA terminator on its antenna input, this should cut the actual transmitter power (and received distance) significantly.

I did an initial test with transmitter and receiver close. It’s clear that the CAD worked on the entire packet. In my test the LED on the transmitter (indicating a packet send in progress) closely followed the CAD detect on the receiver. There was one curious exception and it was consistent, approximately 360mS into the 5079mS packet there would be one CAD detect that failed. It was also noted later that this gap occurred with weak signals too.

With the principle of CAD working on the entire packet established I moved on to seeing if it also worked on weak packets.

The transmitter and receiver were loaded with my link test software and I adjusted the locations of both so that the packets stopped being received at around the 9dBm point.

Here is the link test software output;

Mode1 17dBm,11 16dBm,11 15dBm,11 14dBm,11 13dBm,10 12dBm,10 11dBm,11 10dBm,10 9dBm,8 8dBm,4 7dBm,5 6dBm,0 5dBm,1 4dBm,0 3dBm,0 2dBm,0

Mode1,CSV,11,11,11,11,10,10,11,10,8,4,5,0,1,0,0,0

You can see from the counts that packet reception starts to fail at around the 9dBm point and stops almost completely after 7dBm.

Once the test link had been characterised the receiver was loaded with the CAD detect test software. The positions of the transmitter and receiver were kept the same to ensure consistent link performance.

With the receiver LED being on when CAD succeeds, we can easily tell when a packet is being received. At the start of the descending power sequence (17dBm packet) there is an audio tone transmitted which can be heard on a UHF handheld. When the tone from the remote transmitter is heard you can now count the arriving packets by observing the CAD detect LED. By counting the packets you know which power is in use when the CAD starts to fail, indicated by the LED flickering.

The CAD process was consistent (apart form the gap @ 360mS mentioned above) and started breaking up at around 14 to 13dBm dBm so within about 4 or 5dBm of link failure, this is better performance than expected.

So in approximate terms CAD detect does appear to work on the entire packet, but is only consistent up to around half the distance that the weakest packets are detected.

In the CAD detect software used each CAD detect and print of information to console was taking approximately 62mS. I left the receiver running for 10 minutes to see if there were any false CADs. There were 119 false CADs in 10 minutes or about 1 every 5 seconds or about 1 : 80 CADs are false.

What of the gap in the CAD at the beginning of the packet?  This would appear to be at the time the preamble pattern ends and the packet data starts, so it’s possible CAD will see the preamble, or the packet, but not when both are mixed together.

 

More ESP32 adventures

I have shown in a previous post that it had been possible to cut the deep sleep current of a ESP32 module, with a LoRa device, FRAM and display down to the 8uA region by careful attention to pull up resistors and type of display.

I thought it would be useful to be able to include a Micro SD card into my projects. For the trackers it would be very handy to be able to log GPS data to an SD card. This could be useful if for some reason the LoRa radio link stopped working. For the same reason this would be a useful backup for remote sensor or data gathering applications.

The current taken by micro SD cards seems to vary greatly, the one I was using was consuming 200uA or more when inactive, which would make battery life poor.

I tried switching off the power to just the SD card, but that had the effect of dragging pins on the SPI bus low which increased the sleep current of the LoRa device.

A different approach was needed.

I built up an ESP32 board that used a MOSFET to turn off the VCC power rail to all the devices external to the ESP32, LoRa module, display, FRAM, BME280 sensor and micro SD card.

The picture shows the prototype in action, sleep current was measured at 11uA, and that includes a resistor network to measure the battery voltage and a charger IC to allow for solar battery charging.

This power switching approach also made the software side an easier, it was not necessary to take all the attached devices through a shutdown sequence.

Of course this does mean that all devices need to be re-initialised every time the ESP32 comes out of sleep mode but this is not a difficult issue to deal with.

Locator ESP32 FrontLocator ESP32 Rear

Measuring Low Currents

You may find you need to measure the current consumption of your latest cunning project.

If this current is in the mA range, say from 2mA up to 500mA or more then a standard multimeter will normally do the job. All you need to do it put the multimeter on a suitable current range in series with the power supply, as in the picture;

Measuring current ReducedOne issue that can affect the measurements is the voltage drop across the multimeter. The multimeter measures current by allowing the current to flow through a low value resistor and then measures the voltage drop across that resistor (normally called the shunt). The multimeter can then calculate the current in the resistor.

This voltage drop across the resistor\multimeter is the burden voltage of the multimeter and its consequence is that the project whose current consumption you are measuring is now lower than before.

A Fluke 87 for instance has a burden voltage of 1.8mV per mA on the mA range so if the current flow is 100mA, there is an 180mV voltage drop across the multimeter and the projects supply voltage is now 180mV lower.

What do you do if you want to measure the sleep current of a project which is likely in the tens of uA range? If you have the multimeter on the mA range there won’t be enough resolution to give a good indication of a current in the low uA range.

Also you probably cannot put the multimeter on the mA and then switch to uA as the switching can disconnect power from your project and cause a reset.

So what happens if you start with the multimeter on the uA range? The Fluke 87 has a burden voltage of 100uV per uA on this range so if the project is drawing 100mA when its not in sleep mode the burden voltage of the multimeter will be;

100,000 * 0.0001 = 10v !

Oh dear, with a 10V voltage drop across the multimeter your project is unlikely to run in at all.

Wire Short ReducedSo what to do ?

The answer is fairly straight forward. Start with the multimeter on the uA range and short across it with a bit of wire.

See picture, the multimeter connections are the red and black crocodile clips, the shorting wire is the yellow one.

Then when your project puts itself into low current mode, remove the wire. The burden voltage of 100uV per uA should not cause problems with most projects and you should be able to accurately measure currents down to 1 or 2 uA.

The project shown in the first picture has a sleep current 12.9uA, so the burden voltage is only 1.29mV, which is unlikely to cause a problem. My OWAN B35T (much cheaper than a Fluke !) has a burden voltage of 50uV per uA.

Rather than use a bit of wire to short out the multimeter, make up a switch unit that has power in and out connectors (see picture) with tags for the multimeter connections in the positive line. The switch shorts across the multimeter connections. Short out the multimeter with the switch put the multimeter on the uA range and when the project is in low current mode open the switch. Simple.

Switch Reduced

 

Switch in Use Reduced