RoadTest: Amber Pi Design Kit
Author: stevesmythe
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: TI Simplelink™ CC1310 Launchpad (but no sensors included). There used to be a SimpleLink™ Sub-1 GHz CC1310 Development Kit (but that has now been discontinued).
What were the biggest problems encountered?: Some inconsistencies in the Raspberry Pi part of the getting started instructions in the Amber Pi Reference Manual.
Detailed Review:
The Amber Pi Design Kit is a Raspberry Pi “HAT” with a sub-1-GHz RF interface (the Tarvos-III radio module) provided by AMBER wireless (now part of Würth). The Tarvos-III module features a TI CC1310 wireless MCU, as used in the TI SimpleLink. In the USA the module uses a 915MHz carrier frequency whereas in Europe it is 868MHz. I tested the 868MHz version.
Thanks to my Dad, who had been a radio officer in the UK Merchant Navy in WW2, our house was filled with radio equipment as I was growing up. I love all things wireless so I was very keen to get my hands on the AMBER Pi Development Kit. When this equipment arrived in the post, I got it out of the box and set it up straight away.
Thanks to element14 and Würth for the opportunity to test it.
The radio spectrum is the part of the electromagnetic spectrum with frequencies from 3 Hz to 300 GHz. To prevent interference between different users, the generation and transmission of radio waves is strictly regulated by national laws, coordinated by an international body, the International Telecommunication Union (“ITU”). Generally, a licence is needed to operate radio equipment.
For convenience, the ITU divides the radio spectrum into 12 bands, ranging from ultra low frequency (“ULF” 3 Hz to 30Hz) to tremendously high frequency (“THF” 300GHz – 3000GHz). Each band of the radio spectrum is reserved by ITU for “similar uses” to reduce cross-interference.
The ultra high frequency (“UHF” 300MHz to 3000MHz) band is reserved for common devices such as microwave ovens, mobile phones, WiFi, Bluetooth, Zigbee, NFC and GPS. Part of this band is allocated to “licence free” devices, a good example being 433MHz transceivers commonly used in baby monitors, wireless doorbells etc. This, not surprisingly, is also one of the most crowded bands, and the power levels allowed by these devices are regulated to minimise interference between them. Several years ago, I built a wireless weather station using a pair of Dorji 433MHz modules and Picaxe microcontrollers. It’s still working well on my garage roof.
Within the UHF band, the sub 1GHz range offers some advantages over the 2.4GHz WiFi spectrum:
The longer range and lower power consumption make the sub-1GHz range attractive for some Internet of Things (“IoT”) applications (although it should be noted that the data speeds in the long range mode are drastically reduced).
So a sub-1-GHz RF interface is a radio frequency (“RF”) chip that acts as a transceiver in the 1-GHz part of the UHF band.
The Amber Pi Design Kit comes in an attractive box with foam inserts to keep your Kit safe. Würth have thoughtfully included a removable foam insert that means that, once you have added your own Raspberry Pi, you can stow the whole thing away in the box. There’s even a space for you to stow your official Raspberry Pi Power Supply. Sadly, the UK’s three-pinned plug is too big and you can’t get the lid on the box properly. You’d be OK with a Raspberry Pi 4 and Power Supply as it is smaller.
| {gallery} Unboxing |
|---|
 |
 |
 |
 |
The Amber Pi circuit board is produced in a rather alluring deep red colour. It includes three sensor boards and an empty board connected to the SPI interface of the Raspberry Pi:
Würth have provided C-code drivers for each of the sensors.
The Tarvos-III Plug is an USB-radio-dongle that operates as remote station to the Amber Pi using compatible radio profiles. With this dongle, a bidirectional wireless bridge can be established to a PC.
The kit consists of one Amber Pi (transmitter) board with the sensors and one Tarvos-III Plug USB stick – the receiver. The Amber Pi and the Tarvos-III Plug each come with a dipole antenna with SMA-connector.
Although the Amber Pi Development Kit does not include a Raspberry Pi, element14 kindly supplied a Raspberry Pi 3 for the RoadTest.
The Amber Pi board itself combines an 868MHz (or 915MHz if you are in the US) RF half duplex transceiver with a sensor shield/”HAT” for the Raspberry Pi. The transceiver (branded by Würth as the Tarvos-III) combines an RF core with an ARM Cortex M3, two crystal oscillators and voltage regulation. The M3 exposes UART, GPIO and reset pins and does the job of allowing the user to control the RF core as a “slave” simply by sending the correct sequence of bytes over UART. The Tarvos-III module is contained inside a metal package.
The Tarvos-III Plug USB stick is essentially a Tarvos-III transceiver with an FTDI USB -TTL 3v3 serial convertor (but without the long cable).
The SDK provided by Würth packages up the different byte command sequences, calculates the correct checksum and presents them to the user’s application in a more friendly format (e.g. “CMD_SHUTDOWN_REQ” to turn off the transceiver).
Here are the operating parameters for the board:
The default state of the board is that it is powered by the Raspberry Pi that it sits on. If you wish, you can power it from the built-in CR2032 coin cell holder. To do this, you need to set jumper J16 to the leftmost two pins.
The Amber Pi Kit is aimed at engineers looking to evaluate the Tarvos-III transceiver as the basis for their own designs. It could also be of interest to hobbyists looking for a sub-1-GHz transceiver.
Although some of Würth's marketing presents it as an IoT solution, as it stands, it isn’t really. It’s an RF sensor solution (and there is nothing wrong with that!). To make it into an IoT device, the user would have to develop their own application to receive the sensor readings and send them to the Internet.
The receiving device would then need to be running an application that sends the data received by RF via UART to the Internet. The documentation for the Amber Pi Development kit mentions none of this. It does describe how you can run a terminal program on your PC to view the data received by the Tarvos-III Plug USB stick, but doesn’t mention how you could get this data to the Internet. In this review, I show how you can turn the kit into an IoT solution.
The main documentation is pretty good and consists of the:
I also referred to the documentation for the three provided sensors:
Having three different temperature sensors reminds me of the story about the man whose house was full of clocks, none of which showed the same time. According to the documentation, the HTS221 has the most accurate temperature sensor of the three, so I used that one in my testing.
The Amber Pi Reference Manual walks you through downloading Raspbian, flashing it onto an SD card and configuring the Raspberry Pi interfaces ready for the Amber Pi board. For my main testing, I used the supplied Raspberry Pi 3, but I also tried using a Raspberry Pi Zero. This also worked fine as a lower-power deployed solution but the using the Code::Blocks development environment on it was painfully slow. In the end, I didn't test it with the Raspberry Pi 4 as my only Pi 4 was otherwise occupied. However, since I applied for the RoadTest, Würth have confirmed that (with a couple of extra tweaks), it works with that too.
After setting up the Raspberry Pi, the Reference Manual then takes you through installing the:
“Why Code::Blocks?”, I hear you asking. The answer is that Amber Pi’s RF stack and drivers (for the sensors) and example code is written in C and apparently they used Code::Blocks to develop the SDK.
Code::Blocks is a free cross-platform IDE that runs on the Raspberry Pi and supports C (as well as C++ and Fortran). On the Raspberry Pi, it uses the GNU GCC compiler (v8 on mine). It’s a bit of an odd choice, I think. The Geany IDE has been included in recent versions of Raspbian but Code::Blocks doesn’t seem to have been updated since 2017.
The Reference Manual goes on to explain how to install the Amber Pi SDK in Code::Blocks, and then describes how to compile and run the example application. This application simply transmits readings from each of the sensors every second. However, you can run different versions of the application by commenting out different pre-processor directives (e.g. #if 1 …#elif0 … #endif - green text in the screenshot above). The other versions are to test the Amber Pi in receive mode and to test the different Tarvos-III commands and print the responses to the terminal. These all worked as expected. Screenshot from testing the different Tarvos-III responses is below:
I was interested to read in the Manual that the Tarvos-III module can be run as a repeater to extend the range of sending devices in a network. Each Tarvos-III can be configured to listen on the configured channel and forward on all received packets except the ones addressed to itself. Coupled with "long range mode" (see Test 4 below), you could obtain huge geographical coverage using this technique.
Note: The documentation (even the current online version) pre-dates the Raspbian Buster Linux Debian distribution (released July 2019) and do not quite align with the current process (e.g. you can’t turn off Bluetooth before configuring WiFi because there is now a guided setup routine when you first boot up). “Serial port” and “serial console” interfaces can now be switched separately in Raspberry Pi Configuration but the screenshot in the manual just shows “Serial”. Some of the instructions refer to the AMB8826 driver but this driver is now known as Tarvos-III. If you are going to rename your product, you’d think it wasn’t too hard to update the documentation for it, but Würth apparently didn’t get that message.
The instructions seem to have missed the step of setting the path so that the GNU GCC compiler can be found. This results in an error message.
Test 1
The first test I carried out was simply to run the example code on the Raspberry Pi and receive the transmitted data on my PC using the Tarvos-III Plug USB stick. On Windows 10, the FTDI drivers for the Tarvos-III Plug are automatically installed and an additional COM device is created whenever the USB stick is inserted. To see the data coming in, the Manual recommends installing the HTerm terminal emulation program. This is a pretty standard terminal emulator, but does the job (on Windows or Linux but not available for MacOS). You just need to set up the communications parameters (port, baud rate etc.). This is covered in the Amber Pi Reference Manual. HTerm has a convenient feature where you can start a new line every x characters. With a fixed length payload, this makes the output easier to read, with a new “packet” every line. I got a range of around 75 metres between transmitter (indoors) and receiver out on the street. This would be relevant to use cases such as remote monitoring of utilities such as electricity and gas meters.
Transmitter (Amber Pi/Raspberry Pi):
Receiver (Tarvos-III Plug/PC):
Test 2
As you can see from the screenshot above, this is not a particularly user-friendly format for viewing sensor data. I decided to use my old friend Node-Red to process the incoming data stream and view it on a Dashboard. This was much easier on the eye.
Note: I ran Node-Red on my PC, but you could just as easily run it on another Raspberry Pi. This would require you to install the FTDI drivers on the Raspberry Pi. There are instructions in the Manual.
My setup makes use of an additional Node-Red Node called Node-Red-Serialport. Assuming you already have NPM/Node-Red installed, it is just a matter of running npm install node-red-node-serialport in a terminal window. This adds a new node to your palette. It just needs to be configured with port, baud rate etc.
Now that the data is streaming in, it needs to be parsed and sent to the Dashboard.
Each time data is transmitted, the Amber PI adds a "start signal" 0x02. Also, each set of sensor data is exactly 113 characters long (assuming no data is screwed up or lost). In the Serialport node, you can wait for the 0x02, then read 113 characters into a Node-Red message.
That message included the Hex control commands (the first four characters and the last two), so they had to be stripped out, which resulted in a simple character string as a payload.
Then I configured a little Javascript function node to extract the numeric values from the string so they could be sent to the dashboard.
The output of the splitter is the numeric values of each of the sensor readings, which can then be displayed on the Node-Red Dashboard.
The beauty of using Node-Red is that you can publish the sensor data to the Internet. First, it needs to be converted into JSON format (without the non-printing characters) .....
.... and then it can be streamed outto the Internet using the MQTT node.
And here is the whole flow, with the data being sent both to the dashboard and the Internet:
This turns the Amber Pi into an Internet-enabled device. Here's the data, arriving in the cloud via CloudMQTT and captured with MQTTlens:
Very nice!
As I was just playing around, I didn't implement any security here, but it's perfectly easy to do with CloudMQTT and Node-Red. Of course, between the Amber Pi transmitter and receiver, the data is unencrypted and, potentially, anyone within range with a similar receiver could listen in. It seems unlikely, but it would be worth thinking about. You could encrypt the data before transmission and decrypt at the other end if necessary. The type/strength of encryption willl depend on your security requirements.
Test 3
You don’t actually need a Raspberry Pi to use the Amber Pi. All you need is something that can send command strings via UART to the Tarvos-III module on the board. This could be another microcontroller. I tested this by connecting TX, RX and Ground from an FTDI USB -TTL serial convertor cable (3v3 logic level) to the relevant pins on the Amber Pi board. To power the board, I put in a coin cell and set the jumper J16.
On another PC, I had the Tarvos-III Plug. I ran Hterm on both PCs. In this setup, you can explore the Tarvos-III radio module command set. You can enter configuration settings via Hterm as well as sending messages to and fro between the two Tarvos-III radios. The screenshot below shows (on the left panel) the transmitter (the Amber Pi) connected to COM26 via the FTDI cable and (on the right panel) the receiver (the Tarvos-III Plug) on COM29.
To send a simple message from one PC to the other, you need to send a byte sequence in hexadecimal from the PC to the Tarvos-III chip via the PC's UART. The byte sequence needs to start with 0x02, which tells the UART to expect a command byte (see the table below). The command to send data is called CMD_DATA_REQ and is initiated by sending 0x00. Next comes a hex byte representing the length of the message (in hex), followed by the message itself (in hex) and finally a checksum byte which is the XOR result of all the previous bytes (including the command byte). In summary,
[start signal] [command byte] [length of message] [message] [checksum]
[ 0x02 ] [ 0x00 ] [ 0x0C ] [0x48 0x65 0x6C 0x6C 0x6F 0x20 0x57 0x6F 0x72 0x6C 0x64 0x21] [0x0F]
In this example (bottom left panel above, ringed in red), on PC#1 I typed the Hex characters 02 00 0C (which is the Tarvos-III command CMD_DATA_REQ) followed by the payload (48 65 6C 6C 6F 20 57 6F 72 6C 64 21) followed by the checksum 0F (which is the result of XORing all the previous characters). The top right panel shows the message received on PC#2 in hex (purple) and ASCII (light blue). I have underlined the message part of the sequence in green.
Here is the main command set:
If you look at the top left panel of the sending PC, the receiving PC has sent back an acknowledgement 02 40 01 00 43, which translates as [start signal] [CMD_DATA_CNF] [length] [status] [checksum], where the "status" byte in this case is 0x00 (ACK received or not requested), the length is 0x01 and the checksum is 0x43.
Test 4
I was keen to try out the “long-range mode” of the Tarvos-III. For this, I used the Amber Pi/Raspberry Pi (and the gtkTerm terminal program) on one end and the Tarvos-III Plug (and Hterm) on the other end.
In addition to the command set above, there are commands that change the stored configuration of the Tarvos-III chipset. These settings are stored in EEPROM so the manual cautions the user not to change these too frequently as EEPROMs "wear out" after around 100,000 writes. The command to change user settings is CMD_SET_REQ (0x09) and the setting in question is RADIO_DefaultRfProfile [0x01]. This can take one of five different values, of which the default is 0x00 and "long range mode" is either 0x03 or 0x04.
"long range mode" is therefore set using the byte sequence:
[start signal] [command] [length ] [settings index] [parameter] [checksum]
[ 0x02 ] [ 0x09 ] [ 0x02 ] [ 0x01 ] [ 0x03 ] [ 0x0B ]
To operate in "long range mode", you need to send the above byte sequence to the Tarvos-III on each end (using the relevant terminal program).
The Tarvos-III acknowledges with 0x02 0x49 0x01 0x00 0x4A
To set back to default mode, the first few bytes are the same but the parameter is 0x00 (and the checksum is obviously different), so the complete sequence is:
0x02 0x09 0x02 0x01 0x00 0x08
The Tarvos-III acknowledges again with 0x02 0x49 0x01 0x00 0x4A. You have to remember to reboot the Amber Pi (using the little white button) and the Tarbos-III Plug (there's a tiny reset button accessible through a small hole - or you could just pull it out of the PC and stick it in again!). If you don't remember to do this (I forgot a couple of time), the settings won't have actually changed.
If you forgot which setting you are currently on, there is a command in the table above CMD_GET_REQ (0x0A), where the settings index is once again 0x01 (RADIO_DefaultRfProfile). This tells you which profile is currently set. You can also retrieve any of the other non-volatile settings in this way.
I didn’t fiddle with the TX power settings and just kept the default (which is the maximum anyway (14dB))
With long-range mode enabled, I tried the demo software provided by Würth. I didn’t think this would work as “long-range mode” doesn’t have enough throughput to transfer so much data. I was right- it didn’t work! For simplicity of testing, I just wrote a simple Python script that uses pySerial to send “Hello World!” once a second in an endless loop.
import serial
import time
ser = serial.Serial(
port='/dev/ttyS0',
baudrate=115200,
parity=serial.PARITY_NONE,
stopbits=serial.STOPBITS_ONE,
bytesize=serial.EIGHTBITS
)
while True:
ser.write(b'\x02\x00\x0c\x48\x65\x6c\x6c\x6f\x20\x57\x6f\x72\x6c\x64\x21\x0f')
# hello world
time.sleep (1)
I put the Amber Pi on a window ledge inside my house that faces my local park. I then went to the furthest extent of the park with my laptop and Tarvos-III Plug and set up Hterm as a receiver. It was technically not “line of sight” as there are quite a few trees in the way. As you can see from the video below, it worked pretty well at a range of about half a mile. With no trees in the way and a more elevated antenna, I expect that a range of over a mile would probably be possible just using the supplied antennae. I can imagine it being used in a perimeter security system on a large estate or farm in conjunction with a microwave/radar proximity sensor to detect unexpected visitors (or maybe a magnetometer buried in the road to detect cars passing).
Being able to transmit sensor data that far and then, via the Tarvis-III stick and another device (PC or Raspberry Pi) to the Internet could have some really useful applications.
Also, the other thing that this demonstrates is that you could easily develop your own sensor application in Python (for example, using the Pimoroni Enviro pHAT). All you need to do is get the sensor readings using an existing Python library and add a “wrapper” that sends the Tarvos-III commands (including checksum) around the data. Another example would be a remote entry/control system using an RFID sensor attached to the Raspberry Pi, which sends the "card read" data back to the PC for validation/processing (with optional remote monitoring via the Internet).
The AMBER Pi kit is a great piece of kit but there are some slightly confusing things about it.
It’s supplied in Raspberry Pi HAT format, but it isn’t a HAT because it doesn’t have the required EEPROM that identifies itself to the Raspberry Pi. No matter – it still works. But then, you think “OK – Raspberry Pi means it will come with example code in Python”. No, it doesn’t. Having chosen to design the kit to work with the Raspberry Pi, it seems odd that Würth then chose to provide the SDK and example code in C rather than Python. The Tarvos-III driver and example code are written in C. It is very unusual to find a Raspberry Pi “shield” that requires you to use C. It makes me wonder why the Raspberry Pi was chosen as the target platform for the board but without support for Python, which has become almost the de facto development language for the Raspberry Pi. Of course I know that the Raspberry Pi runs a version of Linux, which is mostly written in C, but the overwhelming majority of Raspberry Pi users code in Python.
This, then, makes we wonder who the AmberPi development kit is aimed at. If it is aimed at professional software developers, they are unlikely to be working in Code::Blocks. More likely, they’d be using Visual Studio or Eclipse/MCUXpresso or Mbed IDE.
Since the Tarvos-III module has its own ARM Cortex M3 MCU, it doesn’t need the processing power of a Raspberry Pi so an Arduino shield might have been a better choice anyway.
The sensors that Würth provide as part of the Kit plug in the side with a clumsy six-pin connector that can easily fall out. Because they are plugged in the side, it makes the whole thing (with the Raspberry Pi underneath) a bit unwieldy. I guess the idea is that you can leave out the ones you don’t want (or add your own on the proto-board) and save power. Hanging them off the side reduces self-heating too, I suppose (although the board does still get slightly warm on top of the Raspberry Pi).
But when you think about it, the sensors are really nothing to do with the Tarvos-III radio chip – they just connect straight through to the Raspberry Pi underneath. Personally I think it would have been better either to leave them out or include them on the main PCB so they don’t take up space. The three sensors that they chose are OK, but you end up with three temperature sensors which is a bit pointless.
Since the board duplicates the Raspberry Pi headers, it might have been good to allow the customer to provide their own sensors. The antenna would be in the way of a full-sized HAT, but a smaller “pHAT” (like the Pimoroni Enviro pHAT) would work fine.
Despite some misgivings, I really like the Amber Pi Kit. Würth have put a lot of effort into the product, and everything about it is of the highest quality. I just think they may have pitched it slightly wrongly. Without having to change any hardware, Würth could open up this kit to a much wider market by writing a Python library for it, and an associated Python demo program. This would work with smaller pHATs like the Enviro pHAT, or with individually-connected sensors. By providing a different antenna connection on the board, there could be space to allow a full-sized Raspberry Pi HAT on top of it.
Top Comments
stevesmythe - excellent review - your experience in radio and serial communications shows. I like how you used Node Red in doing your IoT example. Working on an AWS IoT example even though the road test…
I am glad stevesmythe was selected because the review made good points as well has helped my understanding the project/device.
Cheers!
Nice road test report.
DAB