If you’re attempting to setup the Zero without Wi-Fi, the best method I’ve found is to utilize Ethernet over USB. This permits SSH over USB. There is quite a few guides illustrating this, but they all assume the host (the computer which you’re connecting the Pi to) will bridge with it’s own internet connection. This gives the Pi access to the router so it will be assigned an IP / register it’s local domain name.
The following steps rehash every other tutorial, but assigns a static IP address to the Pi so you don’t have to worry about bridging.
Modify the config.txt file in the boot parition of the image by adding the following line to the bottom of the file:
Modify cmdline.txt by appending the following after rootwait. Make sure to only use a single space character between settings in the file.
Create a file named ssh to enable sshd on boot.
touch ssh # done! :)
In the rootfs partition of the image modify /etc/dhcpcd.conf to setup a static IP:
I’ve been working on Arrow for a while now, but I think it’s time I put it to rest for a bit and write down what has been completed.
I’ve learned lots of fun things from this project (and some horrible things…like AX.25 and the FCC limitations on the 2M band’s data rates!) and I hope someone in the future can make use of it or would be willing to work with me to encourage further development!
What is It?
Currently, Arrow is a full fledged TNC which means the following KISS parameters are supported: TX Delay, TX Tail (why is even a thiiiiing?!?), Slot Time, and Persistence with built-in BLE connectivity and a 2M radio which is frequency agile. In addition to AFSK for AX.25, the radio supports FKS, GFSK, MFSK, and OOK along with M-ary options.
What is a TNC?
TNC for the uninformed stands for Terminal Node Controller in the amateur radio space….Yeah, I didn’t get much from that the first time I heard it either. In fact, I still don’t. I recommend reading the Wikipedia page for a primer.
In short, a TNC is a modem which was used in the early days of packet radio (actually lives on today mainly in APRS) to send digital data from your computer over audio. TNCs were fantastic because they allow anyone with radio capable of sending audio (the most common kind when TNCs were all the rage) to send digital data. You can think of it as the cooler cousin of your 56K dailup modem, but typically way slower.
TNCs were originally used around about the same time the internet was in it’s infancy. The infrastructure and cost at the time was that amateur hobbyist could setup internet link networks using what amounts to their walkie talkies, their home computer, and I hope you can guess it at this point – yes, their TNC.
Why did I do it?
I want to explore and eventually create a new standard for packet radio in the Amatuer space which could provide voice, and data. While I’m still far from the dream I knew the solution would need the following:
Use modern digital modulation techniques for better BER at low SNR.
Reverse compatibility or support of AX.25 for APRS.
Cheap to drive adoption
Built-In Radio and Frequency agile
Current Specifications and Capabilities
TI (CC1200) RF Transceiver IC with Balun + Matching Network for 2M (no PA at the moment)
18650 cell w/ built-in charger
Micro-USB connection for charging and UART access for debugging
Arrow uses the KISS protocol over the Bluetooth SPP profile. This means Arrow when connected to a computer, tablet or phone presents itself as a virtual serial port. The KISS protocol is one of the standardized methods used to communicate and configure TNCs; therefore, it is well supported by existing programs (LinBPQ), apps (APRSDroid), and kissattach (Linux’s ax25-tools).
The uC on-board (ESP32) directly samples data from the CC1200 to decode FM AFSK BELL202 utilized for the standard 1200bps AX.25 used for APRS. Here you can see a video using two arrows to send a ping request over AX.25.
This combination provides what amounts to a plug-and-play solution for linking Arrow into existing Amatuer Radio solutions. The combination does have some limitations I hope to address (see below), but I believe hits most of my goals listed above.
The current implementation has the following limitations:
The CC1200 does not support LoRa or PSK.
The output power is very low (+15dBm) and a PA must be added for this to be viable solutions. Please reach out to me if you’re willing to help.
Bluetooth SPP is not supported by iOS, but luckily the code can be adjusted to use a BLE GATT/GAP setup instead.
Where can I get one?
I don’t believe the current solution is viable with its low output power. It does work well as an APRS receiver. If you’re interested in purchasing one feel free to contact me via this forum. The code and electrical design files can be found here. Hack away.
I’ve been working on a project recently with the ESP32.
I purchased 4 raw ESP32-WROOM-32 modules from Digi-key, soldered them to my hardware, and then attempt to flash them over the JTAG interface. Every attempt of programming the module left me with the dreaded all ones seen blah blah blah error.
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01
All of the existing documentation online suggested a hardware fault so I went into hardware troubleshooting mode until I became fully confident the hardware was not an issue. After much thrashing around, I finally noticed the module were pre-programmed as it was dumping data over the UART port. I managed to re-flash the hardware using the UART interface instead and then the JTAG interface was accessible.
This left me with the following understanding: 1. It’s possible for the firmware to “brick” the JTAG interface 2. ESP32 modules from espressif can potentially come with firmware pre-installed.
I’ve recently been forced to work on an antenna matching issue at work which has been fun and terrifying at the same time (my favorite combination personally). See, I don’t have any traditional RF experience. Everything has been learned on the job / via independent studies; therefore, there I have quite a few gaps I’m trying to fill.
The miniVNA tiny runs between $350-$600 dollars which is two to three orders of magnitude less than a traditional professional VNA new or used. That being said, I didn’t expect much. The best part was I didn’t even really know what to expect because I didn’t know what was important :). I thought measuring the reflected power on a few antennas I had laying around would interest people.
At work we have an Agilent E5071C (running Windows XP) with the ECalibration kit (yaas). The green traces are the miniVNA and blue is the Agilent device.
The first two antennas are monopoles which came with a RTL-SDR based SDR. I’m guessing they’re aircraft bands? The measurements between the two VNAs are quite close. The antenna base is a mag-mount which I placed on the most hearty ground plane I could find. This was my most repeatable test. These sweeps are from 100MHz to 1.2GHz The other tests have the antenna support via a cardboard box sitting on top of the same ground plane. They consist of sweeps from 100MHz to 3GHz.
I don’t like the squiggles in the miniVNA measurement. I’m not sure what the cause is or what to call them? Increasing the calibration points in the range of measurement did not seem to improve the measurement. I believe the Agilent’s output power is higher, but I didn’t see a difference in measurements when I dropped it to -20dBm. I believe whatever these squiggles are the difference in the pass regions.
[Update]: The squiggles are entirely related to the calibration setup. The antennas supplied with a fixed coaxial cable which is huge no-no when performing VNA measurements unless the cable itself it attached during the calibration.
The next two antennas are in the 900MHz / ISM band. I believe their results are quite respectable. You can see a spike around 1.5GHz. It was impossible to remove this with calibration and averaging. It’s advertised the dynamic range of the miniVNA is suppose to be 50dB at 500MHz. I would like to know how to measure the dynamic range for it’s entire operating range so I could estimate if my intended measurement is impossible.
The forth comparison is quite different. It’s likely my fault as this was quite an ad-hoc setup and performed on my lunch break.
Dynamic Range Testing
I put 10 seconds of thought into how I could measure the dynamic range of the miniVNA when measuring transmission or reflected powered, and I thought I figured it out. I decided I would use a variable RF attenuator.
For the transmission measurement, the RF attenuator was placed between the DUT and the DET ports. The lost should be equal to the set RF attenuator and remain flat across the spec’d range for the attenuator (so I assumed). The attenuator I was using was spec’d from DC to 1.5GHz.
Luckily, I was right for once. The plot’s legend lists the amount of attenuation selected in dB. The x-axis is frequency, and the y-axis is power measured at the DET port. The following tables shows some basic statistics from 1MHz to 1.5GHz. There appeared to be a constant 0.3 to 0.24 dB error.
I’ve been working hard to make IdeasX deployable for testing in a real world environment. I’ve also be cleaning up the code based to make it easier for others to hopefully join in on the fun. Attached is the user-manual for the IdeasX Alpha.
If you believe you’d be interested in helping or have potential users please don’t be afraid to contact me.
This morning I visited my favorite coffee shop and decided to fool around with my RTL-SDR T.V. tuner. I’ve used it once before to decode the information sent via my car’s fob. At the time, I was interested in attempting to crack how the “code” sent to my car was encoded, but I was quickly discouraged by the level of encryption. Jamming the TX to a car and then replaying it later is a much more effective method.
This morning I was simply exploring the functionality of it again in preparation for spurious signal detection on a job site later in the week. I loaded up GQRX and took a look around 900MHz and I found a few cool FM signals.
Here you can see what I believe is FSK signal at 930MHz. I recored the audio using a narrow-band FM demodulator and opened it in Audacity to see if I could see any data / preambles / or sync periods for the receiver. Amazingly, I could!
Here you can see what a believe is a preamble followed by a sync period for the receivers clock. Pretty wild! I’ll zoom into the data right after the sync period now.
The preamble appears to have a period of 27ms which is approx. 37Hz followed by the sync period which is 1-2ms (audacity isn’t really built for this and isn’t giving a ton of resolution). This means the data is being clocked at around 1 – 0.5 kHz. Not blazing fast by any means.
Interestingly, this is later followed by a sync period with an identical clock and then another which appears to double the clock. I’m guessing the transmitter sends some basic information at a low data rate for receiver’s with a crappy RSSI and then additional information for those with a decent RSSI value.
I decided to extend the clock through out the signal w/ Pinta (the Linux version of paint) to see if I could determine the encoding scheme (NRZ, Manchester, etc). As expected, I literally have no idea what I’m doing and extending th clock didn’t really reveal anything to me. I would expect the data to sampled on either the rising or falling edge, but appears to be needed on both edges for to detect some of edge transitions. Manchester / Bi-phase is kinda outta the question right away based on the length of some of the pulses.
I think when I get some time and I’m tired of IdeasX, I’ll build a receiver in GNUradio which will sync sampling based on the edge transitions, examine common encoding techniques, and then bust this thing. I tried to open an existing NFM receiver design, but it appears to be using some dated blocks.