Surplus GPS "mouse" receiver and AVR input protection

Somewhere in the back of my mental to-do list I have a project with GPS, NMEA and precise clock (as in hh:mm:ss, not in the digital electronics sense). While I could use the ubiquitous Wi-Fi connection to query an NTP server, I prefer a solution that gets the timestamp without needing a user/password. As a bonus, it tells me the position as well.

A local HAM sells surplus GPS-only receivers (no GLONASS, no Galileo). They require 5V (later found that the range is 3.5V to 5.xV) and speak out NMEA at 4800 baud 8N1. The module inside is one of the GlobalSat series, probably BR-355S4. At least that model number provided a spot-on description of the pinout and existing wiring.

I wired it to a serial TTL/USB adapter and the dongle kept disconnecting from the computer. Both dongles I own. Weird. I needed to see what was going on, so I fired up the oscilloscope. Surprise! The NMEA data out of the surplus GPS dongle is RS-232, with -10/+10V! BTW, I couldn't get the data decoder of the Hantek scope to decode anything out of it.

In order to fix the signal levels I assembled a simple BJT adapter, which also inverts mark/space as in RS-232 logic "mark" (or logic "1") is the negative voltage and "space" (logic "0") is positive WRT ground. In TTL serial, "1" is 5V and "0" is 0V. This let me use the dongle and a GPS decoder software on the computer.

The adapter is 10k resistor into the base of any BJT (BC547, 2N2222, whatever). Emitter to ground. 4k7 from +5V to the collector. You can add a diode between ground and the base, with the cathode on the base side. The diode limits the Vbe reverse voltage to 0.7V. TTL output is at the collector.

The seller told me he could read the data with an Arduino just fine. How comes? Well, many Arduinos use an Atmel AVR ATmega328 processor, whose inputs are protected like this:

From an Atmel datasheet, it's all inside the chip.

 

Those two diodes clip the -/+10V right into the AVR microprocessor and everything looks fine, but might break in the future.

Even if I will use the GPS mouse with an AVR micro, I will include the BC547 adapter.

Checking a static discharge trick with the NanoVNA at UHF

Today I received a question about a post from 8 years ago: how to tame the static build-up in a GP or collinear antenna. Back then I had done some research and concluded that a high value non-inductive resistor could be used, especially at low TX power or RX only.

Now that I own a NanoVNA I can confirm that the impedance is not affected. I quickly reused the LoRA antenna from last Summer, which turned out to be resonating at 750 MHz (if we trust the NanoVNA). This is the curve on a 300 MHz span (well, it stops at 900 MHz on the right):

Just the "open" GP antenna.

 

Then I added a 10 kohm 1/4W resistor across radiator and radials and the result is almost identical (the marker has moved):

After adding the 10kR across. See next picture.

The very (quick && dirty) antenna under test.

So, if we trust the NanoVNA at the upper limit of its working range, this trick does not compromise the impedance. I might also have been lucky on the single experiment I've made, so do your measurements first.

My current LoRA "DX" is 64 km

After few experiments with spread factor and the GP antenna, thanks to TTN Mapper service I can visualize which gateways have received my LoRA signal on 868 MHz.

On the South facing balcony the signal travels 64 km at SF7 BW125 and the RSSI is still respectable. The strongest link at SNR = 8 dB is "just" 48 km long. Both of these long distance paths are in line of sight or very close to it. A total of 5 gateways received my transmissions.

When I moved the transmitter on the North facing balcony I hit 3 new gateways, two of which are available on TTN Mapper. The maximum distance here is about 38 km, but there is absolutely no line of sight path between us.

That makes a total of 7 (8) TTN LoRAWAN gateways that can receive and relay to the cloud my LoRA messages

Simulating a LoRA node GPS position on TTN

A simple way to see your LoRAWAN node or gateway coverage is to use the TTN Mapper service.

In order to get my node visible on TTN Mapper I had to enable the Mapper Integration within my Application and output notes's position. TTN Mapper documentation says that either the node sends its position in the payload or you can "pair" it with a smartphone app and keep both close to each other (ie the same vehicle, the same bag, ...).

OTOH if the node sends its position it must be decoded into a JSON through some code written in the web console, Decoder section under Payload Formats. So, why not write a static Decoder function that returns the required variables?

You need to produce latitude and longitude. Optionally altitude and hdop. If a node isn't moving, that's quite easy! Recover the coordinates in your preferred way (smartphone GPS app, GPS tracker, a web mapping service, ...) and fill in your code like this:

function Decoder(bytes, port) {

  var decoded = {};

  // your node's actual coordinates
  decoded.latitude = X;  // a value like 10.456 (this is North-South or equator)
  decoded.longitude = Y; // a value like 80.123 (this is East-West of Greenwich)

  // your node's height above ground (or is it m.a.s.l.?)
  decoded.altitude = Z;

  // your position accuracy, 5 is fine
  decoded.hdop = 5;

  return decoded;
}

Once the Decoder function is saved, all further transmissions within your TTN Application will carry those variables (added cloud-side once the data is received through a gateway).

Can you see a cheating danger in here? I do. But fortunately there isn't a LoRA distance competition, yet.

Let's get my signal as far away as possible, as strong as possible!

RaspberryPI and LoRAWAN with SX1276

I had laying around a SX1276 LoRA module for some months and following an IoT discussion at work I thought it would be the right time to play with it.

Instead of wiring an Arduino board with level converters (or use a 3v3 Arduino Nano, which I have), I opted to use an old, single-core, 512 MB RAM, Raspberry Pi B+: wiring is straightforward and I can debug+control it remotely over SSH.

Not that I have meaningful data to transmit. I am interested in the RF part of the whole thing since 868 MHz lies between 70 and 23 cm HAM bands and everyone writes wonders about the LoRA modulation scheme. Because of that I chose the software that offered the fastest way to get a signal on the air with the support of TTN. I used arduino-lmic-rpi with bcm2835-1.64 driver. The RPi distro is based on Debian 8 with kernel 4.9.35, don't ask me its name.

The TTN part is well documented: you need to create an Application and register your device on their portal. Then get Device EUI, Application EUI and App Key which have to be inserted into the .cpp file. Pay attention that DEUI and AEUI need to be reversed, so LSB first. Compile and run.

If everything is correct and your LoRA node can reach a gateway nearby, your transmissions will begin to appear on the web console. You need a TTN gateway in your area and it must be able to receive your transmission!!

Performance? My signal is being received by 4 gateways and a couple of them seem to be quite far away (but in line of sight).

Nothing new so far, I have only replicated someone else's work.

Weird behavior of ZS-042 RTC modules (DS3231)

First of all: all these ZS-042 RTC modules were paid about 1 USD each and come from not-certified sources. 

One night I decided to measure the 32K output of some DS3231 ZS-042 RTC modules. I wanted to see what difference would make if I retouched the aging register. This experiment lead to few unexpected discoveries.

1) Maxim DS3231 datasheet mentions 32K output and 32.768 kHz interchangeably. Alright, it is a digital device, so 32K equals 32768 if K=1024 as used for bytes. But we are talking of Hz, not bytes, so I think should be K=1000. Proof? Search for "768" in the datasheet.

2) There are two quite different devices that share 6 characters of the part name - DS3231 - and are distinguished by their suffix: M or SN. The former "M" is 5 ppm with MEMS resonator, while the latter "SN" is 2 ppm with TCXO. In simple terms, "SN" is better than "M". But you can't choose when buying ZS-042 modules and you will receive either model

"M", "SN", "M":notice the deeper blue PCB of "SN"

3) All my ZS-042 modules with DS3231M output a frequency close to 32.700 kHz, while those with DS3231SN are close to 32.768 kHz. The "M" would be loosing 180 seconds/day, 1.5 h/month, but none of them does! Actually I have one DS3231M in my longest running Nixie clock and it is within 5 ppm specification.

Measuring "32K" output of DS3231M.

So, let's forget DS3231SN that are most likely second-hand/pulls but legit. How can a DS3231M that outputs 32700 Hz be so accurate as I observed? If it is genuine, Maxim has a way to calibrate the chip once, before it is sold. If it is a fake, then it is microcontroller with proper firmware and calibration to count the correct number of interrupts. I could sacrifice one and decap it, but then I lack the microscope to examine the silicon die.

Conclusion. Buy the DS3231SN if you need an interrupt rate of 32768 Hz. Otherwise for hobbyist use, they are both worth it.

IoT thermometer online again

The newer firmware I compiled a couple of night ago did not work. The old firmware, compiled with the latest Arduino-ESP8266 combo, did not work either!

So, the problem lies either in the 1.6.4 combo or the OneWire.h library. Or both.

I can't speak for 1.6.4 vs 1.6.1, except that the resulting binary firmware is larger with the latest GUI version. 46% vs 36%, that's a lot, but I should check the actual value in bytes.

Then OneWire.h library was modified to use the internal pull-up resistor in the ESP8266 microcontroller. I think that is quite wrong since the 1wire specification calls for a 4k7 pull-up resistor while nobody really knows the internal R value, that can vary in the future too. Moreover the new pinMode setting breaks existing implementations - like mine - that diligently used the external resistor.

I reverter to the 1.6.1 compiler and the original 1wire library, with the result that my newer firmware compiles, it is small, and it works.

I added a second loop counter to distinguish between counts from power-up and counts since the last TCP o WiFi failure.

IoT thermometer offiline

I did few changes to my IoT thermometer firmware (ESP8266 + Arduino IDE) and something broke: it does not read the DS18B20 anymore. I tried two 18B20: their address is read, which confirms they work and are connected properly, but temperature data is never returned.

Throughout the month since I changed the firmware I updated the Arduino IDE, the ESP8266 libraries and did a Windows update too. Too much to debug in a single night.

As a result my ThingSpeak thermometer is offline.

10k online samples - reset

All was OK, and overnight my DS18B20+ESP8266 online thermometer recorded the 10'000th uninterrupted sample.

But this morning at 11h35 after 10'435 cycles the counter variable was reset. Another reset occurred at 13h50. Either AC power, WiFi or xDSL line were disconnected, or several of them together.

The firmware needs new features that help keeping track remotely of failure reasons. Back to coding, then!

10k online samples

If all goes well, my ESP8266-based online thermometer will reach ten thousand uninterrupted samples in the next hours. That's a bit more than 6 days. Actually it survived a xDSL outage, and the counter was reset (memo: keep two counters). Nothing to be really proud of, but it somehow proves that the code produced by the ESP-Arduino IDE is stable enough for a long-term project.

It's IoT time! Wireless online thermometer with ESP8266 and DS18B20

IoT, Internet of Things, is not rocket science anymore. Grab an ESP8266 WiFi module, a USB-to-serial adapter and few wires later you are programming it through the familiar Arduino IDE. The most annoying part is providing 3.3 V at 300+ mA as power supply. That's about 10 USD if you already have a computer for programming.

For this initial test I am uploading my shack room temperature to thingspeak.com in the "ZYW Home" channel.

The circuit reads temperature every 60 seconds (almost 62 seconds, actually) and uploads it to the cloud. The temperature sensor is a 1-wire DS18B20. The dashboard shows the average temperature in buckets of 10 minutes and how many measurements have been made since power-on.

Incidentally the latter number provides two more information:

1. power outage at home if "cycles" restart from 1
2. xDSL outage or problems if there is a gap or no data upload

 I want to add another temperature sensor for outside and, when ESP-201 modules will come, a solar panel for reading solar illumination. Since ESP-201 allows deep-sleep state, the whole thing could even be battery powered and solar recharged.