Showing posts with label SDR. Show all posts
Showing posts with label SDR. Show all posts

Monday, November 9, 2020

GOES17 Satellite Image Reception with Nooelec Kit and Raspberry Pi

These are my (admittedly sometimes long and rambling) thoughts and more of a "review" of my recent purchase. I'm planning a second blog with just the details on setting up. Stay tuned.

My first "full disk" image was pulled from the GOES-17 Satellite on November 8!

I've been wanting to learn about satellite reception and SDR signal processing for quite some time. I have pretty much zero experience here. I've never even owned a TV satellite dish. This is certainly not my first SDR product from Nooelec. I first received their NESDR Smart RTL-SDR as a birthday present several years ago, and really enjoyed setting up OpenWRT on EA3500 with RTL-SDR Stream. 

I was inspired to buy the Nooelec kit on Amazon after reading about it on the RTL SDR blog, in particular the quite excellent online tutorial on GOES 16/17 Weather Satellite Reception. This was somewhat of a gamble, as I bought mine before any of the reviews on Amazon. (there are now several 5 star reviews!)

I first tried 137.2W GOES-S (GOES-17).

See also the reddit PSA PSA: What you need to know about GOES-13:

The hardware and software requirements for successful GOES-13 decoding are completely different from GOES-16/17 and all other L-Band geostationary weather satellites, do not expect the same setup that works for LRIT/HRIT to work with GOES-13

Update: The USRADIOGUY GOES Satellite Imagery Reception is a great place for info, that would have been quite helpful had I known about it when I started. 

Note that if you go looking for those PDF files at the end in the resources section, they are no longer available. I contacted NOAA support and they responded within 24 hours and even included the files! I submitted an upstream PR, but it looks like there has not been much activity recently. I have a copy in my WIP GOES-Setup docs.

When the kit arrived, I thought the dish was all one piece, as it arrived in one of the biggest Amazon boxes I've ever received. Is the box half full or half empty? I think it is twice as big as it needs to be, just the right size for two of them:


The out-of-box experience was a bit frustrating. There was pretty much no documentation included on assembly or operation. The only thing included was a thank-you card with a link to start.nesdr.com which as of the time if this writing, just redirected to nooelec.com/store/qs with nothing more than basic information on how install the drivers. 

Update: there's now a helpful Set-Up Instructions page on the Nooelec site, and they've added a setup picture on the Amazon product page:


The "driver download" is actually just an old (Version 2.3 from 2017) of Zadig, not actually the drivers. The Nooelec web site was also annoying, as well: Google Chrome would do this annoying oscillation when hovering over the little question mark icons to view the pictures. It was exceptionally frustrating to just view the web picture. Within 24 hours of my message to support, the Nooelec folks fixed that!

In any case, there's not much to do in Windows anyhow, as the XRIT Decoder for GOES Satellite is another $125, as noted on Twitter; note in particular the link to A minimal LRIT/HRIT receiver. But I wanted to at least see if everything was working in Windows.

Nooelec has several SAWbird Low Noise Amplifiers ("LNA") for NOAA, the iridium and Inmarsat and other satellites, but the one shipped in this kit was the GOES flavor with a 1688 MHz Center Frequency: specifically the "premium" version with an aluminum enclosure. Note there's another bare board version.

The kit ships with a USB to power adapter. I had no idea if I am supposed to use it or not, as their web site claims:

 "Each module allows for 3 different power options, but you should only power with one option at any given time! The recommended power input through the SMA output port (for bias-tee capable SDRs like the NESDR SMArTee XTR) is 3V-5V DC". 

As the NESDR SMArTee XTR was also part of the kit, I assumed the power adapter is superfluous. However the web site also states "Our recommendation is the NESDR SMArTee XTR v2, which contains a bias-tee capable of powering the SAWbird GOES module with bias power". Not a single one of  the nesdr xtr items made any mention of a "V2". There's one that looks similar, a Nooelec NESDR SMArt XTR SDR - Premium RTL-SDR w/ Extended Tuning Range, Aluminum Enclosure, 0.5PPM TCXO, SMA Input and another that looks exactly the same, but is labeled as Nooelec NESDR SMArTee XTR SDR - Premium RTL-SDR w/ Extended Tuning Range, Aluminum Enclosure, Bias Tee, 0.5PPM TCXO, SMA Input. (note that it mentions the "bias tee") I'm hoping the Amazon description of "The NESDR SMArTee XTR SDR unit will automatically feed the LNA through a built-in always-on Bias-T" is accurate and this will actually power the SAWbird.

Update: yes, it does! The power adapter is not needed; it's a bonus!

"There is no need to use the external power option.  We opted to include the cable as it allows for easier use for customers who might want to use a different SDR for decoding than what came in the bundle" -- Nooelec Support

The SAWbird was initially equally frustrating; an SMA connector on each end with absolutely no indication of which end is input and which is output. 

Update: Apparently somehow my SAWbird snuck through QA missing the silkscreen (perhaps that makes it a Collector's Edition?)

There's a poor quality picture on the Nooelec site that shows the bare board version has the input on the USB-side of the device:


As those labels are barely visible, it is at least reassuring to see the output label on the other end:


Although I suppose it makes sense to have power input on the antenna input site of the SAWbird, it ends up being the opposite end of the USB input on the SMArtee device. So in the case of no bias-tee, you have power at opposite ends.

Update: the kind support folks at Nooelec pointed out that there should be a silkscreen as on the Hydrogen Line SAWbird as shown in this image from their product web page, confirming that yes the input from the antenna is on the USB port end:


On the topic of input, see the RTL SDR blog, in particular the part:

Either use low loss coax cable or a USB extension cable to get the LNA and/or RTL-SDR out to the antenna.  ... We strongly recommend using as little coax as possible after the LNA too. The SAWbird LNA doesn't have enough gain to push the signal through long runs of coax. If you're forced to use long runs of coax, use a secondary LNA. Preferably use a USB extension cable to reduce coax runs

I would certainly have preferred a long stretch of active USB cable instead of 10m (30 feet) of LMR400 cable. Although yes the LMR400 is "low loss", it is certainly not "no loss". This Pasternack Product Listing, and in particular the datasheet indicates that there's fairly significant loss in the 1.7GHz range and shown from this snip of Times Microwave Systems graph:


After reading this blog, the Nooelec folks kindly responded with this helpful information:

"The snipped of text from the blog website you quoted is lacking a bit in detail.  As general advice (for which it was intended) it's appropriate.  However, the details matter.  The required level of gain from the 1st & 2nd stage amplification on the SAWbird LNA will be contingent on the signal strength from the antenna (which is higher from our custom mesh than most normal installations).  Further, it assumes a lossy cable (most people at best use RG58, which has insertion loss 4x higher than the included LMR400).  Without getting into all the finer details, for most installations there will be about 10dB of headroom from the SAWbird before issues should start to crop up that might require a secondary LNA.  That would be about 150' or more of LMR400 :)  There should be zero difference if you try to decode at the output of the SAWbird vs. after the LMR400 included other than the gain on the SDR which would be more than sufficient to compensate for it.  What matters more is the noise figure, which is dominated by the signal chain at and before the first LNA in the SAWbird.  That is why we use high quality LMR400 on the antenna as well, and why that length is short, and why we mention it is crucial to keep the SAWbird as close to the antenna as possible." -- Nooelec support


On to Raspberry Pi setup... See my prior blog on Raspberry Pi Headless Setup

Do not install the RTLSDR USB hardware into an already powered-on Raspberry Pi! The RPi crashes from the power surge. Yes, I learned this the hard way. I never trust the SD card after such a crash, so I started over.

I ran the install for the Raspberry Pi. It takes quite some time to download and install everything:

sudo apt-get install -y \
    build-essential \
    cmake \
    git-core \
    libopencv-dev \
    zlib1g-dev \
    librtlsdr-dev

# be sure librtlsdr-dev is installed *before* compiling! 

git clone --recursive https://github.com/pietern/goestools
cd goestools
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local
make
sudo make install    
  

Yes, without the sudo for make install, I saw this error:
  
Install the project... -- Install configuration: "RelWithDebInfo" CMake Error at cmake_install.cmake:41 (file): file cannot create directory: /usr/local/share/goestools. Maybe need administrative privileges. make: *** [Makefile:140: install] Error 1


There are two components to receiving satellite images, that I ran in separate putty sessions. One is the goesrecv which, as the name implies, is the data stream receiver. The other key software component that runs completely separately, either on the same RPi or another computer, is the goesproc which actually processes the data stream and turns it into images. Amazing images.

Note the "source" just refers to one of the other sections in the config file with parameter settings:

[demodulator]
# mode = "lrit"
mode = "hrit"
source = "rtlsdr"

# The section below configures the sample source to use.
#
# You can leave them commented out to use the default values for the
# demodulator mode you choose ("lrit" or "hrit"). To use and configure
# any of them, uncomment the section below, and change the demodulator
# source field to match the source you want to use.
#

# [airspy]
# frequency = 1694100000
# gain = 18

[rtlsdr]
frequency = 1694100000
sample_rate = 2000000
gain = 30
bias_tee = true

# [nanomsg]
# connect = "tcp://1.2.3.4:5005"
# receive_buffer = 2097152
# sample_rate = 2400000

[costas]
max_deviation = 200e3

# [clock_recovery.sample_publisher]
# bind = "tcp://0.0.0.0:5002"
# send_buffer = 2097152

[quantization.soft_bit_publisher]
bind = "tcp://0.0.0.0:5001"
send_buffer = 1048576

[decoder.packet_publisher]
bind = "tcp://0.0.0.0:5004"
send_buffer = 1048576

# The demodulator stats publisher sends a JSON object that describes
# the state of the demodulator (gain, frequency correction, samples
# per symbol), for every block of samples.
#[demodulator.stats_publisher]
#bind = "tcp://0.0.0.0:6001"

# The decoder stats publisher sends a JSON object for every packet it
# decodes (Viterbi corrections, Reed-Solomon corrections, etc.).
[decoder.stats_publisher]
bind = "tcp://0.0.0.0:6002"

# The monitor can log aggregated stats (counters, gauges, and
# histograms) to a statsd daemon. Because this uses UDP, you can keep
# this enabled even if you haven't setup a statsd daemon yet.
[monitor]
statsd_address = "udp4://localhost:8125"


Then run
goesrecv -c goes.conf -v -i 1
  

Note if you see an error: Invalid downlink type: then you forgot to uncomment the hrit or lrit in the [demodulator] section of the config file. I opened Issue #101 to perhaps address this for others. 

For reference, if the receiver is getting no data (such as the case when sitting in the house on the kitchen floor for me during initial setup), the output looks like this:
pi@raspberrypi:~ $ goesrecv -c goes.conf -v -i 1
Detached kernel driver
Found Elonics E4000 tuner
Disabled direct sampling mode
[E4K] PLL not locked for 0 Hz!
Allocating 15 zero-copy buffers
2020-11-08T22:29:39Z [monitor] gain:  3.99, freq:    39.0, omega: 8.166, vit(avg): 2167, rs(sum):    0, packets:  0, drops:  6
2020-11-08T22:29:40Z [monitor] gain:  4.57, freq:    -7.6, omega: 8.166, vit(avg): 2205, rs(sum):    0, packets:  0, drops: 12
2020-11-08T22:29:41Z [monitor] gain:  4.59, freq:    26.5, omega: 8.166, vit(avg): 2182, rs(sum):    0, packets:  0, drops: 11
2020-11-08T22:29:42Z [monitor] gain:  4.60, freq:     7.4, omega: 8.167, vit(avg): 2194, rs(sum):    0, packets:  0, drops: 12
2020-11-08T22:29:43Z [monitor] gain:  4.61, freq:   -13.3, omega: 8.167, vit(avg): 2179, rs(sum):    0, packets:  0, drops: 11
2020-11-08T22:29:44Z [monitor] gain:  4.62, freq:   -41.2, omega: 8.167, vit(avg): 2186, rs(sum):    0, packets:  0, drops: 12
2020-11-08T22:29:45Z [monitor] gain:  4.60, freq:   -16.9, omega: 8.167, vit(avg): 2194, rs(sum):    0, packets:  0, drops: 11
^CSignal caught, exiting!
2020-11-08T22:29:46Z [monitor] gain:  4.58, freq:   -27.7, omega: 8.167, vit(avg): 2185, rs(sum):    0, packets:  0, drops:  2
Reattached kernel driver
  

Many of the blogs seemed to make a big deal about leveling, having accurate compass, and other positioning issues. I don't think any of that is essential. The only thing really important is stability. I did buy an inexpensive angle locator on Amazon:


So the only thing I actually measured was the initial inclination of the dish boom - which btw is aluminum, so the magnetic feature didn't help much here. I pointed the dish in the general direction of the satellite as indicated for my location from www.dishpointer.com. Then I loaded up juice ssh on a mobile device (or you could take a laptop), and manually adjusted the dish to get the vit(avg) values as low as possible.

And don't be discouraged if all packets are initially dropped, it may take a bit of time for the signal to lock:
pi@raspberrypi:~ $ goesrecv -c goes.conf -v -i 1
Detached kernel driver
Found Elonics E4000 tuner
Disabled direct sampling mode
[E4K] PLL not locked for 0 Hz!
Exact sample rate is: 2000000.052982 Hz
Allocating 15 zero-copy buffers
2020-11-09T15:49:02Z [monitor] gain:  2.82, freq:    34.9, omega: 2.157, vit(avg): 1149, rs(sum):    0, packets:  0, drops: 40
2020-11-09T15:49:03Z [monitor] gain:  3.07, freq:    26.5, omega: 2.157, vit(avg): 1151, rs(sum):    0, packets:  0, drops: 54
2020-11-09T15:49:04Z [monitor] gain:  3.07, freq:    12.2, omega: 2.157, vit(avg): 1150, rs(sum):    0, packets:  0, drops: 56
2020-11-09T15:49:05Z [monitor] gain:  3.07, freq:    -4.6, omega: 2.157, vit(avg): 1172, rs(sum):    0, packets:  0, drops: 54
2020-11-09T15:49:06Z [monitor] gain:  3.08, freq:    -7.8, omega: 2.157, vit(avg): 1148, rs(sum):    0, packets:  0, drops: 57
2020-11-09T15:49:07Z [monitor] gain:  3.08, freq:    -1.2, omega: 2.157, vit(avg): 1166, rs(sum):    0, packets:  0, drops: 57
2020-11-09T15:49:08Z [monitor] gain:  3.08, freq:    13.2, omega: 2.158, vit(avg): 1164, rs(sum):    0, packets:  0, drops: 51
2020-11-09T15:49:09Z [monitor] gain:  3.08, freq:    -9.9, omega: 2.157, vit(avg): 1143, rs(sum):    0, packets:  0, drops: 52
2020-11-09T15:49:10Z [monitor] gain:  3.08, freq:    32.7, omega: 2.158, vit(avg): 1217, rs(sum):    0, packets:  0, drops: 52
2020-11-09T15:49:11Z [monitor] gain:  3.09, freq:  -870.8, omega: 2.157, vit(avg):  821, rs(sum):   16, packets: 19, drops: 35
2020-11-09T15:49:12Z [monitor] gain:  3.09, freq: -2376.1, omega: 2.157, vit(avg):  199, rs(sum):   76, packets: 55, drops:  0
2020-11-09T15:49:13Z [monitor] gain:  3.09, freq: -2352.7, omega: 2.158, vit(avg):  196, rs(sum):   65, packets: 56, drops:  0
2020-11-09T15:49:14Z [monitor] gain:  3.09, freq: -2351.0, omega: 2.157, vit(avg):  196, rs(sum):   76, packets: 57, drops:  0
2020-11-09T15:49:15Z [monitor] gain:  3.09, freq: -2391.0, omega: 2.158, vit(avg):  195, rs(sum):   64, packets: 58, drops:  0
2020-11-09T15:49:16Z [monitor] gain:  3.09, freq: -2377.3, omega: 2.158, vit(avg):  199, rs(sum):   83, packets: 55, drops:  0
2020-11-09T15:49:17Z [monitor] gain:  3.10, freq: -2337.0, omega: 2.158, vit(avg):  197, rs(sum):   89, packets: 57, drops:  0
2020-11-09T15:49:18Z [monitor] gain:  3.09, freq: -2385.5, omega: 2.157, vit(avg):  195, rs(sum):   52, packets: 58, drops:  0
2020-11-09T15:49:19Z [monitor] gain:  3.09, freq: -2393.7, omega: 2.158, vit(avg):  196, rs(sum):   72, packets: 56, drops:  0
2020-11-09T15:49:20Z [monitor] gain:  3.10, freq: -2389.4, omega: 2.158, vit(avg):  196, rs(sum):  103, packets: 56, drops:  0
  

# Example configuration file for goesproc
#
# This tool is designed to run on streaming data (live or recorded)
# and product whatever is listed in this file. A single product can be
# processed multiple times (e.g. with different contrast curves,
# different scale, or different annotations) by listing multiple
# handlers for that same product.
#

# GOES-16 mesoscale region 1 imagery is stored at ./goes16/m1/YYYY-MM-DD
# The pattern specified in {time:XXX} is extrapolated using strftime(3).
# It can be used more than once if needed.
[[handler]]
type = "image"
origin = "goes17"
region = "m1"
dir = "./goes17/m1/{time:%Y-%m-%d}"

# GOES-17 full disk originals.
[[handler]]
type = "image"
origin = "goes17"
region = "fd"
dir = "./goes17/fd/{time:%Y-%m-%d}"

# GOES-16 full disk, channel 2, with contrast curve applied.
# The section [handler.remap] below applies to this handler.
[[handler]]
type = "image"
origin = "goes17"
region = "fd"
channels = [ "ch02" ]
directory = "./goes16/fd/{time:%Y-%m-%d}"
filename = "{filename}_contrast"

  
Running in a second SSH session:
sudo goesproc -c ~/goesproc.conf --subscribe tcp://127.0.0.1:5004
    

Note that yes, I am using sudo with goesproc. Although it seemed to run without error otherwise, the files that it claimed to have saved were nowhere to be found.

To get the pictures off the Raspberry Pi, you can use pscp that comes with Putty.

That's only fun for the first few pictures, I suggest getting something like winscp.

Sunday, March 31, 2019

ULX3S SDR with ALINX AD/DA

Last year, I wrote about the ALINX AD/DA Module that I found on fleabay. Anyone interested in this board should certainly watch the video posted by opentechlab.

Key tidbits of information from the video:

  • DAC is powered by onboard 3.3V regulator.


  • Output from the DAC is differential 3vpp; (true output is difference) each output goes though a low pass filter for anti-aliasing. 


  • Fed into AD 8056 op-amp to convert differential signal to single-ended and level shift from 3vpp to 10vpp (-5 to +5V)


  • Potentiometer is used to control gain of output.


  • There's a bit of input protection on the ADC.


  • Input filter converts 10vpp to 3vpp for ADC chip.


  • MC34063 Step-Up/Down/Inverting Switching Regulators to generate negative rail for output from single +5VDC supply.



Links:

Sunday, July 15, 2018

Pushing a button. From afar. With LoRa.

This blog entry is about pushing a button. Seems simple enough, eh? Except when the button you want to press is very far from where you are physically located... say, when there's a remote gate control well out of sight and out of range for the remote. Oh, and it is also too far to have any network connectivity. What to do?

My plan is to use LoRa to communicate from an M5Stack console to a distant LoRa32u4, each equipped with a LoRa module; essentially push the button of the remote from afar! The actual pysical button push on the M5Stack will essentially be "sent" (via LoRa message) to the remote 32u4 which will then trigger the actual remote control transmitter. The working prototype is shown here:



How to get there: The first thing needed is to disassemble the remote and determine how it normally works. The remote I am using is a Somfy TR2 similar to this one that can control two different devices. Upon disassembly, the first thing we see is those two buttons each with 4 pins. The buttons appear to be very similar to this Grayhill Gull Wing 95C06C3RAT at Mouser as documented here. Note that although there are 4 pins, it is simply a SPST switch:

Photo credit: Grayhill spec sheet

I confirmed both visually and with an ohmmeter that indeed I have a similar switch and proceeded to connect some external wires to it:

Somfy remote switch wiring

If you look closely, I took the time to wrap the wire around the pin of the switch to make a good mechanical connections, while being careful not to touch any other circuit. It would probably be a good idea to use some hot melt glue and affix the wires to the pc board.

Here, Green is a ground (all 4 pins, 2 from each switch); Orange is BP1 and Yellow is BP2. The top of the battery is labeled as being the positive side. The entire metal surface here is at 3.3V:



This turned out to be an extremely handy arrangement for me: the entire device could essentially be the "load" for an NPN transistor circuit!

Putting an ammeter between either the orange or yellow pins to ground, I found about 0.3mA that would otherwise flow though the button (or a transistor).

Looking at the specs for the 2N3904, the max collector current is a whopping 200mA  max, well over a couple orders of magnitude for what we'll need:


And for a collector current of (we'll round up) to 0.5 mA, we'll have a minimum gain of around 60 to 80 (let's pick a gain of 70 for discussion-sake):




We'll need a base current of around  (0.005A / 70) =  0.0714 mA;  For the current-limiting base resistor, we'll thus need: 3.3v / (0.0000714) ~= 40K ohms. I didn't have a 40K handy, but I did have a bunch of 20K ohm resistors laying around, so I'll use that. It is still well within spec, and will certainly account for any gain drift or degradation.

Our button-pressing supplement thus looks like this (shown for BP1, but the same for BP2):
Note that this circuit will allow our 32u4 to control the remote via a GPIO pin. Fortunately the remote is also smart enough to turn itself off - if for some reason the button remains pressed so that the battery does not drain (such as being poked by your keys in your pocket). In our case: regardless of the state of the pin during power up (or application crash) the battery will be preserved.
The manual prototype looks like this:



Note the red wire to drive the base of the transistor is stuffed into the battery holder for the picture. Once in operation this red wire will instead be the GPIO output from the 32u4.

Next, we need to make sure the remote is actually working! As mentioned in my previous blogs on M5Stack LoRa Range Issues as well as this fun project using OpenWRT on EA3500 with RTL-SDR Stream, I have an inexpensive NooElec SDR, that is simply amazing - particularly given the price! With this hardware, and the some software, we'll be able to "see" the remote signal.

The last time I used Cubic SDR, it was working fine. Today? Nothing. Erg. Gotta love Windows. App starts, no complaints, but no signal. A little bit of googling, and there's the Quick Start Guide. First thing I noticed was mention of my old friend, zadig. Sure enough: during one of the the Windows updates, the default driver was changed for some bizarre reason. Here's the screen just before correcting it:



And tada! Exit Cubic SDR (no need, at least for me, to reboot computer)... relaunch Cubic SDR app... then pressing Start for my RTL2832U device:


The waterfall immediately starts! Press the button on the remote a few times, and we can see the pulse at about 433.5 MHz. Notice the messy side-band noise, as well as someone else continuously transmitting at about 432 MHz:



I have the source code for all this on GitHub here: https://github.com/gojimmypi/LoRa-GPIO (note there are also Development and M5-RadioHead branches, but after a bunch of GitHub fussing, I think the master branch is now up to date). The projects are VisualMicro extensions to Visual Studio, but I suspect the Arduino code would work just fine in the Arduino IDE.

More to come...

Monday, February 12, 2018

M5Stack LoRa Range Issues

Investigating 32u4 to M5Stack LoRa poor range issues; Background information & initial tool setup.

Well, after my last post regarding the fascinating world of FPGA programming, I really thought this next post would continue on that topic. I really want to try out Luke's tiny FPGA board. Alas I've encountered another issue on a project that warrants sharing and someplace for me to keep my notes.


TL;DR

  • Misc details and notes on LoRa
  • VisualMicro ESP32 USB Debugging caused by new driver version
  • NESDR issue with SDR software and driver install
  • LoRa Range issue still unresolved, stay tuned for part 2


Late last year, I finally decided to buy a couple of "DIYmall LoRa32u4 LORA RA-02 Module Development Board Long Range Communication 1KM LiPo Atmega328 SX1278 with IPEX Antenna for Arduino" devices when Amazon had one of their "Lightening Deal of the Day" sales. Not to be confused with LoRaWAN - these are simple serial-type broadcast devices but with very long range. Getting them to talk to each other was ridiculously easy mainly thanks to the great Adafruit Feather 32u4 with LoRa Radio Module tutorial and sample code.

Perhaps there's some software to do LoRaWAN with these (if anyone knows, let me know ) - however I don't have any service providers nearby and the gateways are expensive.

edit 2/18/18: here's a video on creating a LoRa gateway:


By the time my LoRa modules arrived, I had forgotten the title explicitly called out the "RA-02 Module". In hindsight, I'm surprised the Adafruit code worked at all, given their description naming their LoRa device as a Adafruit Feather 32u4 LoRa (RFM9x).  Apparently the RA-02 and RF95 libraries are "close enough" - as my 32u4 appears to have the exact same RA-02 module as used on the M5Stack LoRa module. (I wonder what, exactly is on the Adafruit device?)

Which reminds me: be sure to check the frequency of the respective LoRa devices: they need to match not only each other, but also be allowed in respective county of use!

  (source: RF Wireless World)

After having the proof of concept working with the two 32u4 devices (RadioHead RFM95 libraries)  - which I was able to show them working hundreds of meters apart through very obstructed signal path and certainly not a straight line-of-site (e.g. hill, buildings, trees, etc)... I thought it would be cool to have a display module on one end, controlling the GPIO's on the other.

Some time ago, I had ordered an ESP32-based M5Stack so I decided to use this for a "console" along with their LoRa Module to talk to a very remote 32u4. Seems simple enough in concept, eh? Ha! Nothing is ever as easy as is is supposed to be.

First, the M5Stack core library uses different Sandeep Mistry LoRa drivers. (see also github) Thinking that "LoRa is LoRa", I assumed that they would work together. Indeed the workbench test was a complete success the first time.

However, the first real field test was a disaster. Taking the dog for a walk with an M5Stack connected to USB battery pack in hand, I expected to be tweeting success far from home. I was barely out of WiFi range across the street when the M5Stack stopped receiving messages from the 32u4. Certainly a long way from kilometer LONG Range.

As it turns out, KongDuino recently left a rather interesting blog review of the M5Stack and LoRa modules. It would seem that I'm not the only one with LoRa range problems. If it was easy, it wouldn't be any fun - right?

Note that the 32u4 devices use so little power, that the Anker portable power supply turns off after a few minutes - perhaps thinking nothing is actually connected. Perhaps a USB hub or something might help for a road trip with it.

I've posted my code on GitHub under a project called LoRa-GPIO. This is a pitiful hack of sample code, but an otherwise operational proof of concept of the 32u4 transmitting a signal for the M5Stack to receive and display.

So to investigate the range issues, we'll need some tools such as break-point debugging and signal analysis.

Note for anyone using VisualMicro for development (like me). If any problems are encountered debugging the ESP32, be sure to check the CP210x USB driver version - particularly just after Windows Updates. There's apparently a known problem with recent drivers not working, Simply select (or install as needed) an older version to fix:



Ok, so anytime there's a signal transmission issue at hand, it is helpful to have some visualization tools. I have the inexpensive Nooelec Smart SDR on hand.

See Using SDR Sharp Quick Start Guide. Download Windows SDR Package from https://airspy.com/download/  Need to disable new security feature that prohibits unsigned drivers.

bcdedit /set testsigning on

Reboot. To turn off:
bcdedit /set testsigning off

Even running zadig as administrator, I was unable to change drivers. So ok, I guess I needed to download new driver installer from the Nooelec Getting Started.  Windows is brutal; it completely removed the prior SDR drivers I had installed and working. Grr,,,

SDR Sharp had complained about the Visual Studio 2015 C++ runtime not being able to be installed (I have Visual Studio 2017 installed)... so rather than fuss with that, I installed the CubicSDR 0.2.2 software also located at the bottom of the Nooelec Getting Started with NESDR page.

Note there's an entire CubicSDR web site, and the most recent version appears to be v0.2.3 released in January of this year (2018) complete with source code on GitHub.

Once finally installed, the LoRa signal can be visualized:


So, ok.. I've fussed with Visual Studio debugging, SDR software install, and typing up all these notes and most of the day has flown by. No progress today on the actual problem of poor LoRa range. Clearly a part two is due and coming soon...









Find gojimmypi at gojimmypi.github.io

I'm currently working on my new blog home at  gojimmypi.github.io After implementing a variety of features such as dark mode , syntax hi...