Windows 10 IoT Core Field Gateways “less is more”

After looking back at the technical support interactions for my Azure IoT Hubs Windows 10 IoT Core Field Gateway & AdaFruit.IO LoRa Windows 10 IoT Core Field Gateway I think removing a “feature” might make it easier for first time users.

In an early version of the software I used to provide a sample configuration JSON file in the associated GitHub repository. Users had to download this file to a computer, update it with their Azure IOT Hub or Azure IoT Central connection string or AdafruitIO APIKey , frequency and device address, then upload to the field gateway.

In a later version of the software I added code which created an empty configuration file with defaults for all settings, many of which were a distraction as the majority of users would never change them.

More settings meant there was more scope for users to change settings which broke the device samples and the gateway.

I have removed the code to generate the full configuration file (starting with Azure IOT Hub field gateway) and included a sample configuration file with the minimum required settings in the GitHub repositories and installers.

I am assuming that if a user wants to change advanced settings they can look at the code and/or documentation and figure out the setting names and valid values.

The new sample configuration file for a Azure IoT Hub telemetry only gateway is

{
  "AzureIoTHubDeviceConnectionString": "Azure IOT Hub connection string",
  "AzureIoTHubTransportType": "amqp",
  "SensorIDIsDeviceIDSensorID": false,
  "Address": "Device address",
  "Frequency": 915000000.0
}

The prebuilt installers available on GitHub post version 1.0.13.0 (Azure IoT Hub) and 1.0.5.0 (Adafruit.IO) will implement this model.

Grove Base Hat for Raspberry PI Windows 10 IoT Core

After some experimentation I have a proof of concept Windows 10 IoT Core library for accessing the Analog to Digital Convertor (ADC) on a Grove Base Hat for Raspberry PI.

I can read the raw, voltage & % values just fine but the Version number isn’t quite what I expected. In the python sample code I can see the register numbers etc.

def __init__(self, address=0x04):
self.address = address
self.bus = grove.i2c.Bus()

def read_raw(self, channel):
addr = 0x10 + channel
return self.read_register(addr)

# read input voltage (mV)
def read_voltage(self, channel):
addr = 0x20 + channel
return self.read_register(addr)

# input voltage / output voltage (%)
def read(self, channel):
addr = 0x30 + channel
return self.read_register(addr)

@property
def name(self):
id = self.read_register(0x0)
if id == RPI_HAT_PID:
return RPI_HAT_NAME
elif id == RPI_ZERO_HAT_PID:
return RPI_ZERO_HAT_NAME

@property
def version(self):
return self.read_register(0x3)

When I read register 0x3 to get the version info the value changes randomly. Format = register num, byte value, word value

0,4,4 1,134,10374 2,2,2 3,82,79 4,0,0 5,0,0 6,0,0 7,0,0 8,0,0 9,0,0 10,0,0 11,0,0 12,0,0 13,0,0 14,0,0 15,0,0 
0,4,4 1,134,10374 2,2,2 3,86,69 4,0,0 5,0,0 6,0,0 7,0,0 8,0,0 9,0,0 10,0,0 11,0,0 12,0,0 13,0,0 14,0,0 15,0,0 
0,4,4 1,134,10374 2,2,2 3,32,66 4,0,0 5,0,0 6,0,0 7,0,0 8,0,0 9,0,0 10,0,0 11,0,0 12,0,0 13,0,0 14,0,0 15,0,0 

It looks like register 1 or 2 (134/10374 or 2/2) might contain the device version information.

The code is available on GitHub here. Next time I purchase some gear from Seeedstudio I’ll include a Grove Base Hat For Raspberry PI Zero and extend the software so they work as well.

public sealed class StartupTask : IBackgroundTask
{
   private ThreadPoolTimer timer;
   private BackgroundTaskDeferral deferral;
   AnalogPorts analogPorts = new AnalogPorts();

   public void Run(IBackgroundTaskInstance taskInstance)
   {
      deferral = taskInstance.GetDeferral();

      analogPorts.Initialise();

      byte version = analogPorts.Version();
      Debug.WriteLine($"Version {version}");

      double powerSupplyVoltage = analogPorts.PowerSupplyVoltage();
      Debug.WriteLine($"Power supply voltage {powerSupplyVoltage}v");

      timer = ThreadPoolTimer.CreatePeriodicTimer(AnalogPorts, TimeSpan.FromSeconds(5));
   }

   void AnalogPorts(ThreadPoolTimer timer)
   {
      try
      {
         ushort valueRaw;
         valueRaw = analogPorts.ReadRaw(AnalogPorts.AnalogPort.A0);
         Debug.WriteLine($"A0 Raw {valueRaw}");

         double valueVoltage;
         valueVoltage = analogPorts.ReadVoltage(AnalogPorts.AnalogPort.A0);
         Debug.WriteLine($"A0 {valueVoltage}v");

         double value;
         value = analogPorts.Read(AnalogPorts.AnalogPort.A0);
         Debug.WriteLine($"A0 {value}");
      }
      catch (Exception ex)
      {
         Debug.WriteLine($"AnalogPorts Read failed {ex.Message}");
      }
   }
}

Grove Base Hat for Raspberry PI Investigation

For a couple of projects I had been using the Dexter industries GrovePI+ and the Grove Base Hat for Raspberry PI looked like a cheaper alternative for many applications, but it lacked Windows 10 IoT Core support.

My first project was to build a Inter Integrated Circuit(I2C) device scanner to check that the Grove Base Hat STM32 MCU I2C client implementation on a “played nice” with Windows 10 IoT core.

My Visual Studio 2017 project (I2C Device Scanner) scans all the valid 7bit I2C addresses and in the debug output displayed the two “found” devices, a Grove- 3 Axis Accelerometer(+-16G) (ADXL345) and the Grove Base Hat for Raspberry PI.

backgroundTaskHost.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\Data\Users\DefaultAccount\AppData\Local\DevelopmentFiles\I2CDeviceScanner-uwpVS.Debug_ARM.Bryn.Lewis\System.Diagnostics.Debug.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.

'backgroundTaskHost.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\Data\Users\DefaultAccount\AppData\Local\DevelopmentFiles\I2CDeviceScanner-uwpVS.Debug_ARM.Bryn.Lewis\System.Linq.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Exception thrown: 'System.IO.FileNotFoundException' in devMobile.Windows10IoTCore.I2CDeviceScanner.winmd
WinRT information: Slave address was not acknowledged.
.......
Exception thrown: 'System.IO.FileNotFoundException' in devMobile.Windows10IoTCore.I2CDeviceScanner.winmd
WinRT information: Slave address was not acknowledged.

I2C Controller \\?\ACPI#MSFT8000#1#{a11ee3c6-8421-4202-a3e7-b91ff90188e4}\I2C1 has 2 devices
Address 0x4
Address 0x53
Raspberry PI with Grove Base Hat & ADXL345 & Rotary angle sensor
Raspberry PI with Grove Base Hat I2C test rig

The next step was to confirm I could read the device ID of the ADXL345 and the Grove Base Hat for RaspberryPI. I had to figure out the Grove Base Hat for RaspberryPI from the Seeedstudio Python code.

I2CDevicePinger ADXL345 Debug output

...
'backgroundTaskHost.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\Data\Users\DefaultAccount\AppData\Local\DevelopmentFiles\I2CDevicePinger-uwpVS.Debug_ARM.Bryn.Lewis\System.Diagnostics.Debug.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
DeviceID 0XE5

The DeviceID for the ADXL345 matched the DEVID in the device datasheet.

I2CDevicePinger Debug output

'backgroundTaskHost.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\Data\Users\DefaultAccount\AppData\Local\DevelopmentFiles\I2CDevicePinger-uwpVS.Debug_ARM.Bryn.Lewis\System.Diagnostics.Debug.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
DeviceID 0X4

The DeviceID for the Grove Base Hat for RaspberryPI matched

RPI_HAT_PID = 0x0004 in the Python code.

The last test application reads the raw value of the specified analog input

public async void Run(IBackgroundTaskInstance taskInstance)
{
   string aqs = I2cDevice.GetDeviceSelector();
   DeviceInformationCollection I2CBusControllers = await DeviceInformation.FindAllAsync(aqs);

   if (I2CBusControllers.Count != 1)
   {
      Debug.WriteLine("Unexpect number of I2C bus controllers found");
      return;
   }

   I2cConnectionSettings settings = new I2cConnectionSettings(0x04)
   {
      BusSpeed = I2cBusSpeed.StandardMode,
      SharingMode = I2cSharingMode.Shared,
   };

   using (I2cDevice device = I2cDevice.FromIdAsync(I2CBusControllers[0].Id, settings).AsTask().GetAwaiter().GetResult())
   {
      try
      {
         ushort value = 0;
         // From the Seeedstudio python
	 // 0x10 ~ 0x17: ADC raw data
	 // 0x20 ~ 0x27: input voltage
         // 0x29: output voltage (Grove power supply voltage)
         // 0x30 ~ 0x37: input voltage / output voltage						
         do
	 {
            byte[] writeBuffer = new byte[1] { 0x10 };
            byte[] readBuffer = new byte[2] { 0, 0 };

            device.WriteRead(writeBuffer, readBuffer);
            value = BitConverter.ToUInt16(readBuffer, 0);

            Debug.WriteLine($"Value {value}");

            Task.Delay(1000).GetAwaiter().GetResult();
         }
         while (value != 0);
      }
      Catch (Exception ex)
      {
         Debug.WriteLine(ex.Message);
      }
   }
}

GroveBaseHatRPIRegisterReader Debug output

'backgroundTaskHost.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\Data\Users\DefaultAccount\AppData\Local\DevelopmentFiles\GroveBaseHatRPIRegisterReader-uwpVS.Debug_ARM.Bryn.Lewis\System.Diagnostics.Debug.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
Value 3685
Value 3685
Value 3688
Value 3681
Value 3681
Value 3688
Value 3688
Value 3683

The output changed when I adjusted the rotary angle sensor (0-4095) which confirmed I could reliably read the Analog input values.

The code for my test harness applications is available on github, the next step is to build a library for the Grove Base Hat for RaspberryPI

RFM9X.IoTCore Payload Addressing

The reason for RFM9XLoRaNet was so that I could build a field gateway to upload telemetry data from “cheap n cheerful” *duino devices to Azure IoT Hubs and AdaFruit.IO.

I have extended the Windows10IoTCore sample application and library to show how the conditional compilation directive ADDRESSED_MESSAGES_PAYLOAD controls the configuration.

When the application is started the RFM9X is in sleep mode, then when the Receive method is called the device is set to ReceiveContinuous.

public void Run(IBackgroundTaskInstance taskInstance)
{
   rfm9XDevice.Initialise(915000000.0, paBoost: true, rxPayloadCrcOn : true);

#if DEBUG
   rfm9XDevice.RegisterDump();
#endif

#if ADDRESSED_MESSAGES_PAYLOAD
   rfm9XDevice.OnReceive += Rfm9XDevice_OnReceive;
   rfm9XDevice.Receive(UTF8Encoding.UTF8.GetBytes(Environment.MachineName));
#else
   rfm9XDevice.Receive();
#endif
   rfm9XDevice.OnTransmit += Rfm9XDevice_OnTransmit;

   Task.Delay(10000).Wait();

   while (true)
   {
      string messageText = string.Format("Hello from {0} ! {1}", Environment.MachineName, NessageCount);
      MessageCount -= 1;

      byte[] messageBytes = UTF8Encoding.UTF8.GetBytes(messageText);
      Debug.WriteLine("{0:HH:mm:ss}-TX {1} byte message {2}", DateTime.Now, messageBytes.Length, messageText);
#if ADDRESSED_MESSAGES_PAYLOAD
      this.rfm9XDevice.Send(UTF8Encoding.UTF8.GetBytes("AddressGoesHere"), messageBytes);
#else
      this.rfm9XDevice.Send(messageBytes);
#endif
      Task.Delay(10000).Wait();
   }
}

On receipt of a message, the message is parsed and the to/from addresses and payload extracted (ADDRESSED_MESSAGES defined) or passed to the client application for processing.

private void Rfm9XDevice_OnReceive(object sender, Rfm9XDevice.OnDataReceivedEventArgs e)
{
   try
   {
      string messageText = UTF8Encoding.UTF8.GetString(e.Data);

#if ADDRESSED_MESSAGES_PAYLOAD
      string addressText = UTF8Encoding.UTF8.GetString(e.Address);

      Debug.WriteLine(@"{0:HH:mm:ss}-RX From {1} PacketSnr {2:0.0} Packet RSSI {3}dBm RSSI {4}dBm = {5} byte message ""{6}""", DateTime.Now, addressText, e.PacketSnr, e.PacketRssi, e.Rssi, e.Data.Length, messageText);
#else
      Debug.WriteLine(@"{0:HH:mm:ss}-RX PacketSnr {1:0.0} Packet RSSI {2}dBm RSSI {3}dBm = {4} byte message ""{5}""", DateTime.Now, e.PacketSnr, e.PacketRssi, e.Rssi, e.Data.Length, messageText);
#endif
   }
   catch (Exception ex)
   {
      Debug.WriteLine(ex.Message);
   }
}

The addressing implementation needs further testing and I’m building sample .NetMF and *duino clients.

Rfm9xLoRaDevice LNA gain revisited

While fixing up the Signal to Noise Ratio(SNR) and Received Signal Strength Indication(RSSI) in a previous post I noted the Low Noise Amplifier(LNA) had High Frequency(LF) and Low Frequency settings.

First step was to update the initialise method parameter list (the parameter list is huge but for most values the defaults are fine)

		public void Initialise(RegOpModeMode modeAfterInitialise, // RegOpMode
			double frequency = FrequencyDefault, // RegFrMsb, RegFrMid, RegFrLsb
			bool rxDoneignoreIfCrcMissing = true, bool rxDoneignoreIfCrcInvalid = true,
			bool paBoost = false, byte maxPower = RegPAConfigMaxPowerDefault, byte outputPower = RegPAConfigOutputPowerDefault, // RegPaConfig
			bool ocpOn = true, byte ocpTrim = RegOcpOcpTrimDefault, // RegOcp
			RegLnaLnaGain lnaGain = LnaGainDefault, bool lnaBoostLF = false, bool lnaBoostHf = false, // RegLna
			RegModemConfigBandwidth bandwidth = RegModemConfigBandwidthDefault, RegModemConfigCodingRate codingRate = RegModemConfigCodingRateDefault, RegModemConfigImplicitHeaderModeOn implicitHeaderModeOn = RegModemConfigImplicitHeaderModeOnDefault, //RegModemConfig1
			RegModemConfig2SpreadingFactor spreadingFactor = RegModemConfig2SpreadingFactorDefault, bool txContinuousMode = false, bool rxPayloadCrcOn = false,
			ushort symbolTimeout = SymbolTimeoutDefault,
			ushort preambleLength = PreambleLengthDefault,
			byte payloadLength = PayloadLengthDefault,
			byte payloadMaxLength = PayloadMaxLengthDefault,
			byte freqHoppingPeriod = FreqHoppingPeriodDefault,
			bool lowDataRateOptimize = false, bool agcAutoOn = false,
			byte ppmCorrection = ppmCorrectionDefault,
			RegDetectOptimizeDectionOptimize detectionOptimize = RegDetectOptimizeDectionOptimizeDefault,
			bool invertIQ = false,
			RegisterDetectionThreshold detectionThreshold = RegisterDetectionThresholdDefault,
			byte syncWord = RegSyncWordDefault)
		{

which became

public void Initialise(RegOpModeMode modeAfterInitialise, // RegOpMode
	double frequency = FrequencyDefault, // RegFrMsb, RegFrMid, RegFrLsb
	bool rxDoneignoreIfCrcMissing = true, bool rxDoneignoreIfCrcInvalid = true,
	bool paBoost = false, byte maxPower = RegPAConfigMaxPowerDefault, byte outputPower = RegPAConfigOutputPowerDefault, // RegPaConfig
	bool ocpOn = true, byte ocpTrim = RegOcpOcpTrimDefault, // RegOcp
	RegLnaLnaGain lnaGain = LnaGainDefault, bool lnaBoost = false, // RegLna
	RegModemConfigBandwidth bandwidth = RegModemConfigBandwidthDefault, RegModemConfigCodingRate codingRate = RegModemConfigCodingRateDefault, RegModemConfigImplicitHeaderModeOn implicitHeaderModeOn = RegModemConfigImplicitHeaderModeOnDefault, //RegModemConfig1
	RegModemConfig2SpreadingFactor spreadingFactor = RegModemConfig2SpreadingFactorDefault, bool txContinuousMode = false, bool rxPayloadCrcOn = false,
	ushort symbolTimeout = SymbolTimeoutDefault,
	ushort preambleLength = PreambleLengthDefault,
	byte payloadLength = PayloadLengthDefault,
	byte payloadMaxLength = PayloadMaxLengthDefault,
	byte freqHoppingPeriod = FreqHoppingPeriodDefault,
	bool lowDataRateOptimize = false, bool agcAutoOn = false,
	byte ppmCorrection = ppmCorrectionDefault,
	RegDetectOptimizeDectionOptimize detectionOptimize = RegDetectOptimizeDectionOptimizeDefault,
	bool invertIQ = false,
	RegisterDetectionThreshold detectionThreshold = RegisterDetectionThresholdDefault,
	byte syncWord = RegSyncWordDefault)
{

Then in the code for configuring the RegLna the frequency band is checked

		// Set RegLna if any of the settings not defaults
			if ((lnaGain != LnaGainDefault) || (lnaBoost != false))
			{
				byte regLnaValue = (byte)lnaGain;
				if (lnaBoost)
				{
					if (Frequency > RFMidBandThreshold)
					{
						regLnaValue |= RegLnaLnaBoostHfOn;
					}
					else
					{
						regLnaValue |= RegLnaLnaBoostLfOn;
					}
				}
				RegisterManager.WriteByte((byte)Registers.RegLna, regLnaValue);
			}

The HF & LF differences where not obviously handled in Arduino-LoRa library and the Semtech LoRaMac node GitHub repository wasn’t so helpful this time.

Not so confident with these changes need to test with my 434MHz devices

Rfm9xLoRaDevice SNR and RSSI revisited

The magic numbers for the high frequency(HF) vs. low frequency(LF) adjustment bugged me

int rssi = this.RegisterManager.ReadByte((byte)Registers.RegRssiValue);
if (Frequency < 868E6)
	rssi = -164 + rssi; // LF output port
else
	rssi = -157 + rssi; // HF output port

int packetRssi = this.RegisterManager.ReadByte((byte)Registers.RegPktRssiValue);
if (Frequency < 868E6)
	packetRssi = -164 + rssi; // LF output port
else
	packetRssi = -157 + rssi; // HF output port

After some searching I ended up at the Semetch LoRaMac node github repository. In that code they had a number of constants which looked like a better approach.

if( SX1276.Settings.Channel > RF_MID_BAND_THRESH )
{
   rssi = RSSI_OFFSET_HF + SX1276Read( REG_LR_RSSIVALUE );
}
else
{
   rssi = RSSI_OFFSET_LF + SX1276Read( REG_LR_RSSIVALUE );
}

I also fixed a couple of bugs I noticed with the maths and the code now looks like this

int rssi = this.RegisterManager.ReadByte((byte)Registers.RegRssiValue);
if (Frequency > RFMidBandThreshold)
   rssi = RssiAdjustmentHF + rssi;
else
   rssi = RssiAdjustmentLF + rssi;

int packetRssi = this.RegisterManager.ReadByte((byte)Registers.RegPktRssiValue);
if (Frequency > RFMidBandThreshold)
   packetRssi = RssiAdjustmentHF + packetRssi;
else
   packetRssi = RssiAdjustmentLF + packetRssi;

This has also got me thing about how RegLna – LnaBoostLf/LnaBoostHf should be handled as well.

Rfm9xLoRaDevice SNR and RSSI

The signal to noise Ratio (SNR) and Received Signal Strength Indication(RSSI) for inbound messages required reading values from three registers

  • RegPktSnrValue
  • RegPktRssiValue
  • RegRssiValue

I had to modify the EventArgs returned to the customer

public class OnDataReceivedEventArgs : EventArgs
{
	public float PacketSnr { get; set; }
	public int PacketRssi { get; set; }
	public int Rssi { get; set; }
	public byte[] Data { get; set; }
}

I was inspired by the RSSI adjustment approach used in the Arduino-LoRa library

// Get the RSSI HF vs. LF port adjustment section 5.5.5 RSSI and SNR in LoRa Mode
float packetSnr = this.RegisterManager.ReadByte((byte)Registers.RegPktSnrValue) * 0.25f;

int rssi = this.RegisterManager.ReadByte((byte)Registers.RegRssiValue);
if (Frequency < 868E6)
	rssi = -164 - rssi; // LF output port
else
	rssi = -157 + rssi; // HF output port

int packetRssi = this.RegisterManager.ReadByte((byte)Registers.RegPktRssiValue);
if (Frequency < 868E6)
	packetRssi = -164 - rssi; // LF output port
else
	packetRssi = -157 - rssi; // HF output port

OnDataReceivedEventArgs receiveArgs = new OnDataReceivedEventArgs
{
	PacketSnr = packetSnr,
	Rssi = rssi,
	PacketRssi = packetRssi,
	Data = messageBytes
};

The values displayed in the Rfm9xLoRaDeviceClient application looked reasonable, but will need further checking