Category Archives: Arduino

Setup a Challenger 2040 LoRa in VS Code

24th February 2024 Karl 1 Comment

I have recently been wanting to play with LoRa radios because reasons. This gives me a way of sending short messages between devices using a lightweight protocol with a range of a couple of kilometres on a bad day. I ended up picking up a Challenger 2040 LoRa manufactured by iLabs from The PiHut, mostly because all the others were out of stock. I then spent three days just getting the radio to initialize in my code.

As the Challenger 2040 LoRa has a lot of unhelpful documentation, this is a practical getting started guide using Platform IO, an alternative to the Arduino IDE, in Visual Studio Code on Windows for this board. Some familiarity with VS Code and Platform IO is assumed.

Installing RP2040 Support for Platform IO

If you have used the Pico 2040 before then you have probably done this already, but if not here is a summary for Windows users – this is for a new installation. The full instructions are on readthedocs.io, if you have it installed already and see the depreciation warning, check the full instructions:

Prerequisites:

Exit from VS Code
Enable long path support:
1. Windows 10/11 Home users may need to activate gpedit, see this Major Geeks how-to
2. Click Window key and type gpedit.msc, then press the Enter key. This launches the Local Group Policy Editor.
3. Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem.
4. Double click Enable NTFS/Win32 long paths and close the dialog.
Install git from: https://git-scm.com/download/win using the defaults.
Restart the computer – this adds git to the path.
Open an Administrator Console/Terminal (Terminal > Right Mouse Click and choose Run As Administrator), then:
Enable long paths in git: git config ——system core.longpaths true

Adding to Platform IO
Now load up VS Code, and in Platform IO create new project, Give it a name (rp2040test) and select Raspberry Pi Pico as the board and Arduino as the framework.

Pi Pico - Platform IO Selection — Pi Pico – Platform IO Selection

Click Finish and let it do its thing. This will give us a platformio.ini file to edit.

[env:pico]
platform = raspberrypi
board = pico
framework = arduino

[env:pico]

platform = raspberrypi

board = pico

framework = arduino

Update this file to be like:

[env:pico]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = pico
framework = arduino
board_build.core = earlephilhower

[env:pico]

platform = https://github.com/maxgerhardt/platform-raspberrypi.git

board = pico

framework = arduino

board_build.core = earlephilhower

When you save the file it takes a few minutes to automatically add the RP2040 SDK and long list of development boards including the Challenger 2040 LoRa to those available in Platform IO. You can now create a new project and choose the Challenger 2040 LoRa from the list of boards, which will give you this default platformio.ini:

[env:challenger_2040_lora]
platform = raspberrypi
board = challenger_2040_lora
framework = arduino

[env:challenger_2040_lora]

platform = raspberrypi

board = challenger_2040_lora

framework = arduino

but I prefer to use the one below.

Initializing the LoRa Radio

This is the part that took me the most time to get working, here is the cheat-sheet. Set platformio.ini as:

[env]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
framework = arduino
board_build.core = earlephilhower
board_build.filesystem_size = 0.5m

[env:challenger_2040_lora]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
framework = arduino
board_build.core = earlephilhower
board_build.filesystem_size = 0.5m
board = challenger_2040_lora
lib_deps = sandeepmistry/LoRa@^0.8.0

[env]

platform = https://github.com/maxgerhardt/platform-raspberrypi.git

framework = arduino

board_build.core = earlephilhower

board_build.filesystem_size = 0.5m

[env:challenger_2040_lora]

platform = https://github.com/maxgerhardt/platform-raspberrypi.git

framework = arduino

board_build.core = earlephilhower

board_build.filesystem_size = 0.5m

board = challenger_2040_lora

lib_deps = sandeepmistry/LoRa@^0.8.0

this also includes the LoRa library.

This is a modified version of the LoRaDumpRegisters.ino example just to show it working. The changes are to have it selecting SPI1 and setting the correct pins for the radio. Remember to set the correct frequency for your region:

#include <Arduino.h>

#include <SPI.h>
#include <LoRa.h>

const long lora_frequency = 868E6;   // LoRa Frequency
//const long lora_frequency = 915E6;

// https://github.com/earlephilhower/arduino-pico/blob/master/variants/challenger_2040_lora/pins_arduino.h
const int lora_cs   = RFM95W_SS;      // 9   LoRa radio chip select
const int lora_rst  = RFM95W_RST;     // 13  LoRa radio reset
const int lora_irq  = RFM95W_DIO0;    // 14  must be a hardware interrupt pin

void setup() {

  Serial.begin(9600);
  while (!Serial)
  {
    ;
  }

  Serial.println("ready");

  LoRa.setSPI(SPI1);   // the library defaults to SPI0
  LoRa.setPins(lora_cs, lora_rst, lora_irq); 

  if (!LoRa.begin(lora_frequency)) {

    Serial.println("LoRa init failed. Check your connections.");
    while (true);                       // if failed, do nothing
  }

  LoRa.dumpRegisters(Serial);
  Serial.println("LoRa init succeeded.");
}

void loop() {
}

#include <Arduino.h>

#include <SPI.h>

#include <LoRa.h>

const long lora_frequency = 868E6; // LoRa Frequency

//const long lora_frequency = 915E6;

// https://github.com/earlephilhower/arduino-pico/blob/master/variants/challenger_2040_lora/pins_arduino.h

const int lora_cs = RFM95W_SS; // 9 LoRa radio chip select

const int lora_rst = RFM95W_RST; // 13 LoRa radio reset

const int lora_irq = RFM95W_DIO0; // 14 must be a hardware interrupt pin

void setup() {

Serial.begin(9600);

while (!Serial)

{

;

}

Serial.println("ready");

LoRa.setSPI(SPI1); // the library defaults to SPI0

LoRa.setPins(lora_cs, lora_rst, lora_irq);

if (!LoRa.begin(lora_frequency)) {

Serial.println("LoRa init failed. Check your connections.");

while (true); // if failed, do nothing

}

LoRa.dumpRegisters(Serial);

Serial.println("LoRa init succeeded.");

}

void loop() {

}

The expected output on the serial port is a list of numbers in hexadecimal format ending with “LoRa init succeeded.”

I hope this is useful and saves much faffing about.

Arduino, Electronics, Interesting

Fancy Blink for Arduino

9th August 2022 Karl

This little blink program for the Arduino blinks an LED to give two short flashes and then a longer pause. The milliseconds are kept in an array ledDelays. It iterates through the array, setting the class=’bash’>interval according where the delayCount pointer is set. The LED state is toggled when the interval is complete.

The char pout[50] is used as a tidy way of outputting to the serial port as some older Arduino board don’t support Serial.printf.

#include <Arduino.h>

#define MONITOR_LED LED_BUILTIN

const int delayCount = 4;
// led blink times in millis, LED state: off,  on, off, on
const uint32_t ledDelays[delayCount] = { 1500, 100, 90, 200}; 

// add more blinks, like so:
// const int delayCount = 6;
// const uint32_t ledDelays[delayCount] = { 1500, 100, 90, 200, 50, 100}; 

int delayID = 0;
uint32_t interval;
uint32_t millisNow;
uint32_t millisPrevious;
bool ledToggle = false;
char pout[50] = {0};

void setup() {

  Serial.begin(9600);
  delay(6000);
  Serial.println("ready");

  pinMode(MONITOR_LED, OUTPUT);

  interval = ledDelays[0];
}

void loop() {

  millisNow = millis();

  if ((millisNow - millisPrevious) >= interval) {
    digitalWrite(MONITOR_LED, ledToggle);

    sprintf(pout, "%d, %d, %d", delayID, ledToggle, interval);
    Serial.println(pout);
    // Serial.printf("%d, %d, %d\n", delayID, ledToggle, interval);

    ledToggle = !(ledToggle);       // change the state of the LED
    millisPrevious = millisNow;     // blink without delay()
    interval = ledDelays[delayID];  // set the delay time for the next iteration
    delayID ++;
    if (delayID >= delayCount) {  // reset the delayID 
      delayID = 0;
    }
  }
}

#include <Arduino.h>

#define MONITOR_LED LED_BUILTIN

const int delayCount = 4;

// led blink times in millis, LED state: off, on, off, on

const uint32_t ledDelays[delayCount] = { 1500, 100, 90, 200};

// add more blinks, like so:

// const int delayCount = 6;

// const uint32_t ledDelays[delayCount] = { 1500, 100, 90, 200, 50, 100};

int delayID = 0;

uint32_t interval;

uint32_t millisNow;

uint32_t millisPrevious;

bool ledToggle = false;

char pout[50] = {0};

void setup() {

Serial.begin(9600);

delay(6000);

Serial.println("ready");

pinMode(MONITOR_LED, OUTPUT);

interval = ledDelays[0];

}

void loop() {

millisNow = millis();

if ((millisNow - millisPrevious) >= interval) {

digitalWrite(MONITOR_LED, ledToggle);

sprintf(pout, "%d, %d, %d", delayID, ledToggle, interval);

Serial.println(pout);

// Serial.printf("%d, %d, %d\n", delayID, ledToggle, interval);

ledToggle = !(ledToggle); // change the state of the LED

millisPrevious = millisNow; // blink without delay()

interval = ledDelays[delayID]; // set the delay time for the next iteration

delayID ++;

if (delayID >= delayCount) { // reset the delayID

delayID = 0;

}

Arduino, Electronics, Hardware

Rebuilding the Vacuum Fluorescent Display

23rd December 2018 Karl

Back in April 2016 I posted details on how a Vacuum Fluorescent Display (VFD) works and a method of driving it from an Arduino type microcontroller using transistors, while this worked well it made for a rather bulky clock. I have now rebuilt the display using proper VFD driver chips, added a rotary switch with LED’s, NeoPixel capability and used a WeMos D1 Mini microcontroller to give me internet access over WiFi so the time and date can be set using the Network Time Protocol (NTP).

This rebuild is much more practical than previously, it is now about 3cm deep and comprises of two boards back to back with pin header plugs/sockets as the interconnects. I have been running the clock for over a year without any problems, apart from having to switch the thing off and back on when Daylight Savings Time changes in the spring and autumn, but that’s a software (lazy programmer) problem.

Power Supply

Three different voltages are needed to operate this clock, 16 Volts for the VFD display anodes, 5 Volts for the microcontroller and NeoPixels and 3.3 Volts for the VFD cathode and other hardware.

From the 12 volt source, I split the power to a XL6009 boost module to supply 16V to the driver IC’s, the 5V power module can supply up to 5A which is enough for around 2 meters of NeoPixels. The 3.3V supply is created using a BA033T fixed voltage regulator running from the 5V module, I have used this to power the VFD cathode, the rotary encoder and VFD driver IC’s as this is the microcontrollers operating voltage.

Driving the Display

To drive the anodes on the VFD display I used three MAX6920 Tube Drivers, these have a four wire serial interface and can switch up to 76V on the display.

The physical connections from the driver IC’s to the VFD anodes (grids and elements, see the previous article for definition) are those that are most convenient for the PCB layout without having to use links or through-hole connections as the order of the pins for outputting the display can be mapped later in software.

In this case, the first anode pin on the display is on the right, but the serial data starts with the first MAX6920 chip on the left. I will explain in more detail in the software section below.

The Cathode is run from the 3.3 Volt supply, it has a 3.3V Zenner diode across it to protect against meltdown in case of over-voltage, the cathode is made from of strands of thin tungsten wires and shows as a short when testing in beep mode on the multimeter.

Rotary Switch

I have used the SparkFun RGB Illuminated Rotary Encoder, as well as the encoding it also includes three LED’s and a push button switch. As the WeMos only has limited number of pins available, I used an MCP23008 I²C I/O Expander. I have covered these encoders in a previous post and have used a similar method here.

In this project it turned out I don’t have much use for the rotary switch, the same result can be achieved with a push button and two LED’s, it goes red when setting the time over WiFi, goes green when the time has finished setting but is off when running normally, the push button displays the date when pushed. I expect the encoder could be used for setting an alarm should I ever have need to add one.

Software

The complete source code I am currently running in the clock can be found on my github repository, it has been written for the Arduino platform and can be considered unfinished and a bit of a mess. In almost all cases this clock will be a custom build with all the scavenged VFD displays being different I’ll be concentrating on how the display is being driven. Note that the software uses Latch and the MAX6920 driver chip uses Load.

To start, here are the physical connections for my VFD display, the display connections are shown looking from the back with pin one on the right, on the anode there are eleven grids and twenty-one elements, each grid illuminates a block of chosen elements. There are three MAX6920 driver chips, the first is on the left data is passed along the serial data line DIN/DOUT to the right:

Connecting the MAX6920 drivers to the display

While I’m not going to worry too much about how the data is sent to the display as this is being handled by the ShiftOutX library it may be useful to have an understanding of the byte order sent to the driver chips.

Breaking out the logic analyser we can see what is going on, in this first image below we can see that between the two markers one and two there are eleven data peaks to match the number of grids on the display the data is processed as a padded eleven character string: ‘ 212848 ‘ the first four contain nothing but the bit selecting grid to be used the next six are busy as they contain the time, and the last is blank. There also appear to be two blank clock cycles after these, this may be a programming error on my part.

the string is iterated so that each grid gets its own character with a very short delay between each this causes the persistence of vision effect and the time appears on the display.

In the next screen capture I have zoomed into more detail, it is showing the fifth grid and is displaying the number two. You can see that there are thirty-two clock cycles sent to the drivers while LOAD is high, this causes the driver chips to direct the data to the outputs. I am not entirely sure why the clock is being run while LOAD is low, I think it may be clearing the buffer before sending the required information.

You can see that 32 bits are sent to the display, but there are 36 pins available on the three MAX6920 drivers, you can also see that the outputs are arranged out of order. How do the drivers know which lines to switch for the display?

First off, an explanation of how the data is constructed then sent to the display. For this example I am sending the number five to the third grid, the data is constructed through the manipulation of a character array in three stages:

1.	blank char array:	00000000000000000000000000000000
2.	set the third grid:	00000000000000000000000000000100
3.	set the number:	00111000011000011100000000000100

Because of the way the bits are ordered when sent to the drivers I have a lookup array VFDlookup to make life easier, in this case grid 3 can be found at position 29 in the VFDdata character array. I start with a blank character array of 32 bits VFDblank and copy this to VFDdata, I then use VFDlookup to find the position of the bit to set: VFDlookup[3] = 29. For the elements the encoding for each character is set in VFDdigits the code for number 5 is 1110000110000111 the code was worked out by experimentation, seeing which element lit up after I had completed the hardware, I have ignored the extra symbols used for the DVD player so I only need to set pins 15-30. Once complete the character array is converted to a unsigned long integer and sent LSBFIRST – Least Significant Bit First via ShiftOut_32.

While that explains the elements encoding to display the correct digit, the grid selection however is a different kettle of fish. I built this clock over a year ago and have forgotten how it works. Grids 1 and 2 are connected to the output pins 1 and 0 on the third driver, pins 2-5 are then skipped, and the rest are connected to the grids, with three more being taken from chip 2. I can’t work out how it knows to skip those pins, or that grid 2 is connected to pin 1. But it is an awesome clock though.

Links and Sources

Github Repository: https://github.com/kazzle101/vfdclock6
WeMos D1 Mini
SparkFun RGB Illuminated Rotary Encoder – UK Supplier
Datasheet: MCP23008 – I/O Expander
Datasheet: MAX6920 – Display VFD Tube Driver
Datasheet: BA033T Fixed LDO Voltage Regulator – 3.3Volt output
Serial to Parallel Shifting-Out with a 74HC595

Arduino, Electronics, Hardware

Making a Printed Circuit Board

7th October 2018 Karl

Finally, I got around to videoing how I make a PCB. This one is for my Fridge Door Open alarm.

Arduino, Electronics, Hardware, Programming

The Fridge Door is Open

29th August 2018 Karl

My fridge door tends to rebound when closed staying open a smidgen and letting all the cold out. Rather than just checking that the door is properly shut, I thought it about time to have a microcontroller make a noise when the door has been left open too long.

This circuit uses an Arduino compatible Teensy LC for all the work, it has a phototransistor to sense the state of the fridge door light, a couple of LED’s one to indicate the power and another that comes on when the door is open. There is also Piezo buzzer to make an annoying noise after forty five seconds of door open time. The unit runs of a 3.7v rechargeable Lithium-ion battery and I have added a recharging circuit that takes power via the Teensy’s 5v USB port.

Circuitry

Note: These diagrams show 3.7v as the supply voltage. The Teensy LC can only tolerate a maximum 3.3V on the data pins, so these circuits are driven from the 3V output on the Teensy. They will all work without modification on the 5v Arduino Uno.

I have used a phototransistor to detect the fridge door light, there are two variants of this circuit light activated or dark activated, the 100k resistor can be replaced with a 100k variable if you need to adjust the sensitivity, the 330k resistor provides a weak pull-down on the output. The phototransistor is being used in switch mode to provide a logical output (rather than active mode which provides an output relative to the amount of light), so the output is connected to a digital input on the Arduino. The BC547 transistor is half of the darlington pair to provide extra gain on the output.

I chose the light activated switch, either will do but will provide different logical outputs to your controller. The circuit is enclosed in a small box inside the fridge and connected by ribbon cable to the controller, the ribbon cable is flat and does not upset the magnetic ‘seal’ on the fridge door.

To make some noise I used a piezo buzzer from an old computer, this is driven through a transistor as the Teensy does not provide enough current to drive it directly.

There is also a push button to provide a reset function if the buzzer is sounding while the door is open.

I have also added two LED’s, one to show power and anther that illuminates when the door is opened.

The final circuit if for recharging the battery, it connects to the 5V connection on the Teensy LC so charges the battery when the USB connection is in use. This has been copied from the MCP3831T datasheet.

Software

This uses an interrupt to listen for the light sensor, when the state changes, the door open pin is read to determine if the door is open or not. If it is then a timer is started, this gives you forty five seconds to complete your task before the alarm sounds. With the door closed the timer is stopped and set back to zero. If the sounder goes off while you are rummaging in the fridge the reset button can be pressed, this restarts the timer from zero again.

#define TEST_LED 13
#define FRIDGE_DOOR 6
#define DOOR_LED 8
#define POWER_LED 7
#define RESET_BTN 9
#define BUZZER 10

volatile boolean doorOpen = true;   // when the light is on
volatile boolean doorTrigger = false;
volatile unsigned long lastFridgeMillis = 0;
volatile unsigned long fridgeTimeoutMillis = 10;

boolean SerialDebug = false;
unsigned long doorOpenDelay = 45000; // 45 second timeout before buzzer sounds
unsigned long doorOpenTime = 0;
unsigned long startTime;
unsigned long previousToneMillis = 0;
unsigned long toneInterval = 20;
boolean soundTheAlarm = false;
boolean outputTone = false;
int toneMelody[5] = { 1600, 1900, 2000, 2100, 1800 };
const int toneMax = 5; 

unsigned long lastDoorOpenTime = 1;
char pout[80]; // for testing

// interrupt function
void fridgeDoor() {
  if ((millis() - lastFridgeMillis) > fridgeTimeoutMillis) {
    doorOpen = digitalRead(FRIDGE_DOOR); // goes high when dark
    lastFridgeMillis = millis();
  }
}

// see if the door is open or closed
void fridgeDoorOpen() {
  if (doorOpen == true && doorTrigger == false) {
    doorTrigger = true;
    startTime = millis();

    if (SerialDebug) {
      sprintf(pout, "door open: %d", doorOpen);
      Serial.println(pout);
    }
    digitalWrite(DOOR_LED, HIGH);
    return;
  }

  if (doorOpen == false && doorTrigger == true) {
    doorTrigger = false;

    if (SerialDebug) {
      sprintf(pout, "door closed: %d", doorOpen);
      Serial.println(pout);
    }
    startTime = 0;
    doorOpenTime = 0;
    soundTheAlarm = false;
    digitalWrite(DOOR_LED, LOW);
    return;
  }

}

// make some noise
void soundAlarm() {

  if (soundTheAlarm == false) {
    return;
  }

  int ii = 0;
  while (ii < 6) {
    if (soundTheAlarm == false) {
      break;
    }
    int i = 0;
    while (i < toneMax) {
      if (soundTheAlarm == false) {
        break;
      }

      unsigned long currentMillis = millis();
      if((currentMillis - previousToneMillis) > 50) {
        previousToneMillis = currentMillis;
        tone(BUZZER,toneMelody[i]-380,60);
        i++;
        }
    }
    ii++;
  }

}

// door open? then increment the timer - sound the alarm 
void fridgeDoorOpenTimer() {

  if (doorOpen == false && doorTrigger == false) {
    return;
  }

  if (digitalRead(RESET_BTN) == HIGH) {
    digitalWrite(POWER_LED, LOW);
    while (digitalRead(RESET_BTN) == HIGH) {
      delay(10);
    }

    if (SerialDebug) {
      Serial.println("reset");
    }
    startTime = millis();
    soundTheAlarm = false;
    digitalWrite(POWER_LED, HIGH);
  }

  // checking once a second
  doorOpenTime = millis() - startTime;
  if (doorOpenTime % 1000 == 0 && doorOpenTime != lastDoorOpenTime) {
    if (SerialDebug) {
      Serial.println(doorOpenTime);
    }

    if (doorOpenTime > doorOpenDelay) {
      if (SerialDebug) {
        Serial.println("Awwooga Awwooga - fridge door open!");
      }
      soundTheAlarm = true;
      soundAlarm();
    }

    lastDoorOpenTime = doorOpenTime;
  }

}


void setup() {

  pinMode(TEST_LED, OUTPUT);
  digitalWrite(TEST_LED, HIGH);

  if (SerialDebug) {
    Serial.begin(9600);
  }

  delay(2000);

  pinMode(DOOR_LED, OUTPUT);
  pinMode(POWER_LED, OUTPUT);
  pinMode(BUZZER, OUTPUT);

  if (SerialDebug) {
    Serial.println("ready");
  }
  digitalWrite(POWER_LED, HIGH);

  pinMode(FRIDGE_DOOR, INPUT);
  attachInterrupt(digitalPinToInterrupt(FRIDGE_DOOR), fridgeDoor, CHANGE);

  pinMode(RESET_BTN, INPUT);
  digitalWrite(TEST_LED, LOW);
}

void loop() {
  fridgeDoorOpen();
  fridgeDoorOpenTimer();
}

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

#define TEST_LED 13

#define FRIDGE_DOOR 6

#define DOOR_LED 8

#define POWER_LED 7

#define RESET_BTN 9

#define BUZZER 10

volatile boolean doorOpen = true; // when the light is on

volatile boolean doorTrigger = false;

volatile unsigned long lastFridgeMillis = 0;

volatile unsigned long fridgeTimeoutMillis = 10;

boolean SerialDebug = false;

unsigned long doorOpenDelay = 45000; // 45 second timeout before buzzer sounds

unsigned long doorOpenTime = 0;

unsigned long startTime;

unsigned long previousToneMillis = 0;

unsigned long toneInterval = 20;

boolean soundTheAlarm = false;

boolean outputTone = false;

int toneMelody[5] = { 1600, 1900, 2000, 2100, 1800 };

const int toneMax = 5;

unsigned long lastDoorOpenTime = 1;

char pout[80]; // for testing

// interrupt function

void fridgeDoor() {

if ((millis() - lastFridgeMillis) > fridgeTimeoutMillis) {

doorOpen = digitalRead(FRIDGE_DOOR); // goes high when dark

lastFridgeMillis = millis();

}

// see if the door is open or closed

void fridgeDoorOpen() {

if (doorOpen == true && doorTrigger == false) {

doorTrigger = true;

startTime = millis();

if (SerialDebug) {

sprintf(pout, "door open: %d", doorOpen);

Serial.println(pout);

}

digitalWrite(DOOR_LED, HIGH);

return;

}

if (doorOpen == false && doorTrigger == true) {

doorTrigger = false;

if (SerialDebug) {

sprintf(pout, "door closed: %d", doorOpen);

Serial.println(pout);

}

startTime = 0;

doorOpenTime = 0;

soundTheAlarm = false;

digitalWrite(DOOR_LED, LOW);

return;

}

// make some noise

void soundAlarm() {

if (soundTheAlarm == false) {

return;

}

int ii = 0;

while (ii < 6) {

if (soundTheAlarm == false) {

break;

}

int i = 0;

while (i < toneMax) {

if (soundTheAlarm == false) {

break;

}

unsigned long currentMillis = millis();

if((currentMillis - previousToneMillis) > 50) {

previousToneMillis = currentMillis;

tone(BUZZER,toneMelody[i]-380,60);

i++;

}

ii++;

}

// door open? then increment the timer - sound the alarm

void fridgeDoorOpenTimer() {

if (doorOpen == false && doorTrigger == false) {

return;

}

if (digitalRead(RESET_BTN) == HIGH) {

digitalWrite(POWER_LED, LOW);

while (digitalRead(RESET_BTN) == HIGH) {

delay(10);

}

if (SerialDebug) {

Serial.println("reset");

}

startTime = millis();

soundTheAlarm = false;

digitalWrite(POWER_LED, HIGH);

}

// checking once a second

doorOpenTime = millis() - startTime;

if (doorOpenTime % 1000 == 0 && doorOpenTime != lastDoorOpenTime) {

if (SerialDebug) {

Serial.println(doorOpenTime);

}

if (doorOpenTime > doorOpenDelay) {

if (SerialDebug) {

Serial.println("Awwooga Awwooga - fridge door open!");

}

soundTheAlarm = true;

soundAlarm();

}

lastDoorOpenTime = doorOpenTime;

}

void setup() {

pinMode(TEST_LED, OUTPUT);

digitalWrite(TEST_LED, HIGH);

if (SerialDebug) {

Serial.begin(9600);

}

delay(2000);

pinMode(DOOR_LED, OUTPUT);

pinMode(POWER_LED, OUTPUT);

pinMode(BUZZER, OUTPUT);

if (SerialDebug) {

Serial.println("ready");

}

digitalWrite(POWER_LED, HIGH);

pinMode(FRIDGE_DOOR, INPUT);

attachInterrupt(digitalPinToInterrupt(FRIDGE_DOOR), fridgeDoor, CHANGE);

pinMode(RESET_BTN, INPUT);

digitalWrite(TEST_LED, LOW);

}

void loop() {

fridgeDoorOpen();

fridgeDoorOpenTimer();

}

Links and Sources

Practical Electronics for Inventors, Third Edition. Paul Scherz and Simon Monk, pub. McGraw Hill, 2013. ISBN 978-0-07-177133-7
A pre-made USB LiPo Battery Charger – 3.7V Single Cell from Hobbytronics or from Sparkfun
Battery Charger MCP3831T Datasheet
TEPT4400 Phototransistor Datasheet

Arduino, Electronics, Hardware

A Box for my Pixles

18th August 2018 Karl

This all started with wanting to modify a cheap camping light by replacing the LED’s with some colourful NeoPixels. I made a Printed Circuit Board to match the existing PCB disc that held the LED’s, as well as a board for an ATtiny85 microcontroller which incorporated a microphone and vibrating motor of the type used in a old mobile phone. The battery and charging circuit came from a cheap (Poundland) USB powerbank but it turned out that the battery from the powerbank didn’t fit in the camping light how I liked (in a measure twice, cut once sort of thing). Instead I made this:

Arduino, Electronics, Hardware

Hacking the Yongnuo Wireless Controller

22nd February 2018 Karl

I wrote this back in May 2017 but it was never finished, I got distracted by other things and I needed the wireless controller for photography. I wrote all this and it would be a shame to delete it, so I am posting it now on the chance there may be of something of interest within.

I use this Yongnuo Wireless Controller in photography to control a number of flash units away from the camera body. It comes in two parts, a transmitter that connects to the hotshoe on the camera and receivers with a hotshoe that connect to the flash, a single transmitter can control any number of flash receivers within the claimed 300 meter range. The transmitter with a couple of receivers can be gotten of eBay for around £35.

Yongnuo Wireless Controller FSK 2.4GHz
RF-600TX transmitter
RF-602RX receiver

[image of transmitter and receivers]

I am looking to:

See how the flash is connected
Investigate how the transmitter works – reverse engineer as much as I can
See if I can control the transmitter directly with an Arduino
See if other devices using the same radio chip can also be controlled
Not destroy the transmitter while examining it

Opening it up

[images of the transmitter insides]

On the board inside you will find:

A power on/off switch
Bi-colour Red/Green LED
A dual-press button with two switches for operating the flash manually
A four way code selector (4 way DIL switch)
An anonymous (no markings) microcontroller – µC
A7105 2.4GHz FSK/GFSK ISM band wireless transceiver

On the underside, my board is marked with the following version and date:

Version: 1.21
Date: 14/04/23 – 23 April 2014

Looking at the datasheet for the A7105 it can work as both a transmitter and receiver and uses an SPI interface for user control, it appears to be popular with the radio controlled RC aeronautical drone community. The receiver looks to be very similar by way of components, using the same radio chip and anonymous microcontroller. I have not examined it in any detail and take care if disassembling as there are three hotshoe connections that need to be desoldered.

Flash Connection

On the Canon camera the hotshoe has six connections but we only need to examine three of these. Looking down on the camera with the lens facing away from you, the main plate where the flash slides in is ground, the large central dot is the flash trigger just below this on the left is the camera ready connection. I assume the rest are for the E-TTL functions and I have not looked at these.

Checking the hotshoe with a multimeter, the flash trigger appears to have a high resistance that decreases when the flash is fired, I suppose this is a legacy of when cameras were more mechanical. The Camera Ready connection goes High – around 5 Volts, to tell the flash to wake up, that you have pressed the shutter halfway, the lens has focused and you are about to take a photo.

To find the duration of the flash signal on the cameras hotshoe I connected an almost flat AA battery between ground and flash to give me 1.2 volts to measure against on the oscilloscope (checking a canon flash itself, the voltage across the flash pin and ground is 4.47 volts). I found that the flash signal is sent by the camera for 352ms, which is quite long considering that a typical shutter speed of 1/125 second for flash photography works out at 8ms, although the amount of time a flash fires for is set on the flash and not by this signal.

Microcontroller Connections

I spent a while tracing out most of the transmitter circuit, I have ignored most of the supporting radio circuitry and the crystal timer as I am wanting to investigate the data side. The parts are also rather small and troublesome to investigate with standard multimeter probes.

RF600TX - Partial Schematic — RF600TX – Partial Schematic

The microcontroller looks to use internal pullup resistors for the input switches, the camera ready signal from the hotshoe switches a transistor to pull pin 16 low on the controller.

Looking at the circuit diagram we see an output to the antenna from pin 8 of the micro controller. This outputs two different square waves when the shutter button is pressed, one for camera ready and another for flash. I think these are being modulated on the transmitter output to produce a radio signal and simplify the transmitter design. Looking at the output from pin eight on the oscilloscope, the two states can be seen quite clearly:

These square wave outputs are always the same, I thought it may change when a different code was chosen through the DIL switches. The transmitter unit does not receive any radio data, and no acknowledgement is made by the flash units.

Using a Logic Analyser

Time to break out the Logic Analyser, this is a cunning device that allows you to see the data being exchanged between the microcontroller and transceiver, I don’t want to get too detailed but think this may help for the following sections.

The data system being used by the A7105 is SPI. The Serial Peripheral Interface bus uses four wires: Chip Select SCS, multiple chips can be on the same SPI bus, but they all have different SCS connections, the master controller chip uses SCS to tell the slave chip it wants to use for data exchange. Serial Clock SCK: This is used to provide time synchronisation for the data exchange with a fixed duration for the highs and lows. Data SDIO: This is the data being sent by the microcontroller and GIO1 is data from the transceiver sent in reply, normally for SPI this is 8 bits, to make a byte.

The naming conventions used here are from the A7105 datasheet, The SPI bus has standard names for data lines; SDIO is MOSI – Master Out/Slave In, GIO1 would be MISO – Master In/Slave Out and SCS is SS – Slave Select. In our case the microcontroller would be the master and the transceiver the slave.

The Logic Analyser displays data in a form that allows you to see the logic, here we can see two bytes of data:

The microcontroller – µC sends data on the SDIO line and listens for replies on GIO1. When the µC sets Chip Select SCS low this tells the transceiver that the µC wants to talk to it. The µC sends a command byte followed by one or more bytes of data – a packet. During the SCS event, data is only transferred while the clock SCK is running.

SPI data, binary data from the highs and lows

We can see that the logic on the SDIO is read every-time the clock goes low, falling edge, a clock tick on the SCK line represents a bit of data, eight ticks make a byte. We now have our binary data: 00100101 for convenience this is converted into hexadecimal 0x25.

When examining an SPI bus check any available datasheets to see if the clock is set to tick on a falling or rising edge, the bit order is Most Significant Bit – MSB or Least Significant Bit – LSB, and the data length (normally eight).

Looking at the A7105 Transceiver

A7105 Block Diagram (a clearer version can be seen in the datasheet)

From the A7105 datasheet the SPI bus is set for the following:

To activate SPI, the SCS pin must be set low
data length: 8 bits
bit order: Most Significant Bit First (MSB)

I have made the following connections to the transmitter. Soldering test leads to the microcontroller (µC) is the most convenient place to do this.

This table shows the Input/Output pins on the transceiver and microcontroller, as well as the colour of wire used for the logic analyser.

A7105	Description		In/Out	µC	Wire Colour
11	SCS	3 Wire Chip Select	I	9	yellow
12	SCK	3 Wire Clock	I	10	orange
14	SDIO	Read / Write	I/O	12	brown
16	GIO1	4 Wire SPI Data Output	I/O	11	red
17	GIO2	4 Wire SPI Data Output	I/O	13	white
	GND	Ground			black
		Trigger Out	O	8	grey

How the A7105 organises data

The transceiver has two data modes, Strobe and Control. There are eight strobe commands to control the various modes the chip supports, these are four bits in length and always begin with a 1, where the transceiver is being operated in 8 bit mode the final four bits are ignored. The Control registers are eight bits in length and are used to configure and read settings from the transceiver, they are eight bits in length, the first bit is always 0 and the second is either 1 for write or 0 for read. The table below shows examples of a write, a read (or more accurately a request, the transceiver replies on GIO1) and a strobe command sent by the µC.

	Address Byte								Data
Bit:	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
Control:	CMD	R/W	Address						Data
Write Example: 0x2 0x1	0	0	0	0	0	0	1	0	0	0	0	0	0	0	0	1
Read Example: 0x42 0xff	0	1	0	0	0	0	1	0	1	1	1	1	1	1	1	1

Strobe:	CMD	Strobe ID			not used				not used
Example: 0xa0	1	0	1	0	0	0	0	0

Examining the A7105 data

Data is exchanged on the SPI during two events, after the transmitter has been switched on, and when you are pressing the camera shutter or the button on the unit.

Power On

When you first switch on the unit, the microcontroller initialises the transceiver with a few hundred bytes of data, I have created this spreadsheet from the SPI data, hex data across is the most useful sheet to view:

In summary the initialisation sequence consists of the following

The microcontroller sets the majority of control registers to default
Internal calibration is started and the microcontroller keeps checking until this is done
Final cleaning up
Place the A7105 into standby mode

Shutter Press

On the SPI the shutter press action has two distinct stages, the preamble and the transmission. The preamble takes the camera out of standby mode and sets the channel it is going to be transmitting on. The transmission broadcasts the camera ready and flash states.

The Preamble
At the beginning of the datacaptue I see a preamble packet sent over the SPI:

Logic Analyser Data - first five bytes of the Preamble Packet — Logic Analyser Data – first five bytes of the Preamble Packet

This preamble looks to only appear when the flash is first operated after the transmitter unit has been switched on, subsequent use goes straight to transmit. The fifth byte changes depending on the DIL switch setting on the underside of the unit, as you can see in the four examples given in the table below.

	bytes
DIL switch	strobe		control	data		strobe
0000	0xB0	0xB0	0x05	0xB5	0xF0	0xD0
1000	0xB0	0xB0	0x05	0xB5	0xE1	0xD0
0100	0xB0	0xB0	0x05	0xB5	0xD2	0xD0
1111	0xB0	0xB0	0x05	0xB5	0x0F	0xD0

Taking the first example, we can break this down to see what each byte is doing

SCS	Packet			IN/OUT	Command	Payload	binary
0	0xb0			STROBE	PLL Mode		0b10110000
1	0xb0			STROBE	PLL Mode		0b10110000
2	0x5	0xb5	0xf0	IN	FIFO Data	TX data	0b00000101	0b10110101	0b11110000
817µs gap
3	0xd0			STROBE	TX Mode	transmission begins	0b11010000

It is difficult to work out what is going on here, according to the datasheet you send a packet of data 0xb5 0xf0 to be transmitted to FIFO Data 0x5 and follow that with the strobe command TX mode 0xd0, but what is transmitted bears no relation to the FIFO packet.

We need to look further back in the initialisation sequence and the datasheet, the A7105 has three modes of transmission; easy, segment and extension. We need to undertake a little bit of detective work to find which this is. Chapter 16.4 of the datasheet shows us the two registers used in the initialisation sequence we need to examine:

Bit:		7	6	5	4	3	2	1	0
FIFO I	0x3	FEP7	FEP6	FEP5	FEP4	FEP3	FEP2	FEP1	FEP0
Setting value:	0x1	0	0	0	0	0	0	0	1
FIFO II	0x4	FPM1	FPM0	PSA5	PSA4	PSA3	PSA2	PSA1	PSA0
Setting value:	0x0	0	0	0	0	0	0	0	0

The datasheet does not say directly so we need to go through each modes description to see which is the best fit. Segment FIFO looks good: “In Segment FIFO, TX FIFO length is equal to (FEP [7:0] – PSA [5:0] + 1). FPM [1:0] should be zero”. So our settings: (FEP:0b1 – PSA:0b0) + 1 = 2. The number of bytes sent our FIFO Data packet is also 2.

Further reading of the description “This function is very useful for button applications. In such case, each button is used to transmit fixed code (data) every time. During initialisation, each fixed code is written into corresponding segment FIFO once and for all. Then, if button is triggered, MCU just assigns corresponding segment FIFO (PSA [5:0] and FEP [7:0]) and issues TX strobe command.”

The Transmission
Taking an initial look at the data gathered during a shutter press on the Trigger Out (pin 8 of the microcontroller) we can clearly see the transition from Camera Ready and Flash as we saw on the oscilloscope earlier.

GIO2 shows a mirror of the Trigger Out, but zooming in to the data and I see that it follows the Trigger signal. Looking in the initialisation spreadsheet at SCS event we see that the command 0xc 0x1 was sent for setting the function of the GIO2 pin. Looking at the datasheet this appears to be set as an ‘I am transmitting’ signal, WTR – Wait until TX or RX has finished. If I force GIO2 low by sorting it to ground then the flash does not fire when I press the shutter

In my data capture the Camera Ready signal was transmitted six times, and the Flash signal thirteen times, I am sure this is dependant on the length of time I had the shutter button pressed on the camera.

Apologies for the inconclusive ending, I ran out of time to pursue this further

Links and Sources

A7105 Datasheet and Product information
Logic Analyser: https://www.ikalogic.com/scanaplus/
SPI Data tutorial https://learn.sparkfun.com/tutorials/serial-peripheral-interface-spi
Arduino A7105 library: https://github.com/nh2/arduino-a7105
Reverse Engineering a Hubsan X4 Quadcopter: http://www.jimhung.co.uk/?p=1424 with a description of the A7105 data
SPI data bus and FSK – Frequency Shift Keying on Wikipedia

Arduino, Electronics, Hardware

Using Phototransistors

26th September 2017 Karl

With one of my electronics projects I am wanting to add a couple of phototransistors to make a crude movement sensor and to do this I first need to discover the best way of using them. A phototransistor is sensitive to the amount of light falling upon it, as this increases higher current is allowed through the device. This in turn can be used provide a variable voltage to an analogue input on your microcontroller.

For this posting I am using two different phototransistors, the SFH3710 is a surface mount device smaller than a red lentil and the TEPT4400 is through hole and looks like small white LED and is easier to prototype with, they are both NPN transistors made to respond to visible light at wavelengths around 570nm.

left TEPT4400, right the SFH3710 mounted in stripboard for prototyping

Connecting

A bias, or load, resistor is required to produce an output (V_OUT). This can be above or below the phototransistor.
Common Emitter
The resistor R_C acts to pull-up the voltage, as light increases the output voltage drops.

Common Collector (Common follower)
In this case the resistor R_E acts to pull-down the voltage, as light increases the output voltage increases.

Phototransistor Modes

The Fairchild Semiconductors application notes describe the two modes that phototransistors can be used in; switch and active. The mode is set by the value of the load resistor R_L:

Switch Mode: V_CC < R_L x I_CC
Active Mode: V_CC > R_L x I_CC

Where :

V_CC = Supply Voltage
R_L = Load Resistor (R_c or R_e)
I_CC = Maximum anticipated current

In switch mode the transistor is either on or off, this ‘digital’ output is useful for object sensing or object detection, typically a resistor value greater than 5kΩ is adequate, the output in the ‘high’ state should equal the supply voltage, and for ‘low’ the output should be below 0.8V.

In active mode the output is variable, giving a value related to the amount of light. To use this a low value resistor is required to prevent V_OUT exceeding the supply voltage, using Ohms Law you can find the maximum resistance, the value above which the transistor may respond in switched mode: R_max = V_CC / I_CC, so: 5v / 4mA = 1.2kΩ. Connected up as Common Emitter, selecting a resistor value 30% below this to ensure a margin of error a 875Ω should give 4.5V at the output when completely dark, dropping to below one volt when saturated with light.

The drawback with active mode is that phototransistors have a non-linear response to light, as light increases beyond a certain level their output will suddenly jump and then flatten out, other factors, such as the ambient temperature and the type of light (daylight, fluorescent tubes, LED’s, etc) also affect the value of the output.

Practical Experiments

I want to test that the above is actually true, this circuit uses a white LED pointed at a TEPT4400 along a short piece of black straw to act as a stray light shield. The LED brightness is set using PWM on the Arduino. The phototransistor is setup for Common Emitter output, so the output voltage will drop as the light increases. For active mode R_C was set to 220Ω and for switched mode this was 10kΩ.

The code below uses PWM to fade the white LED up to full brightness, the reading taken from the analog port is a majority candidate reading, where from the ten readings made the one that occurs most often is used as the phototransistor output bounces around, I think this is caused by the PWM, the results are output on the serial port for use in a spreadsheet.

const int sensorPin = A1;
const int LED = 13;
const int pwmOut = 10;
const int numAnalogReadings = 10;
int majority[numAnalogReadings];
int sensorVal = 0;
boolean ledState = LOW;
char pout[40];

// http://www.geeksforgeeks.org/majority-element/
int findCandidate() {

  int maj_index = 0;
  int count = 1;
  for (int i = 0; i < numAnalogReadings; i++) {
    
    if (majority[i] == majority[maj_index]) {
      count++;
    }
    else {
      count--;
    }
            
    if (count == 0)
    {
      maj_index = i;
      count = 1;
    }
  }
  return majority[maj_index];  
}

int multiAnalogRead(int aPin) {
    
  for (int i = 0; i < numAnalogReadings; i++) { 
    int s = analogRead(aPin);
    majority[i] = s;
    delay(random(5,9));    
  }
  
  return findCandidate();
}

void setup() {

  delay(1000);
  randomSeed(analogRead(A0));
  Serial.begin(9600);
  pinMode(LED, OUTPUT);  

  Serial.println("Ready");
  analogWrite(pwmOut, 0);
  delay(1000);

  Serial.println("time\tlight\tvalue");
  
  int i = 0;
  int fadeVal = 0;
  do {
    analogWrite(pwmOut, fadeVal);
    delay(200);
    sensorVal = multiAnalogRead(sensorPin); // analogRead(sensorPin);    
    
    sprintf(pout,"%d\t%d\t%d",i, fadeVal, sensorVal);
    Serial.println(pout);
        
    i++;
    ledState = !(ledState);
    digitalWrite(LED, ledState);
    fadeVal += 5;
  } while (fadeVal <= 255);
  
  Serial.println("finished");
}

void loop() {

}

const int sensorPin = A1;

const int LED = 13;

const int pwmOut = 10;

const int numAnalogReadings = 10;

int majority[numAnalogReadings];

int sensorVal = 0;

boolean ledState = LOW;

char pout[40];

// http://www.geeksforgeeks.org/majority-element/

int findCandidate() {

int maj_index = 0;

int count = 1;

for (int i = 0; i < numAnalogReadings; i++) {

if (majority[i] == majority[maj_index]) {

count++;

}

else {

count--;

}

if (count == 0)

{

maj_index = i;

count = 1;

}

return majority[maj_index];

}

int multiAnalogRead(int aPin) {

for (int i = 0; i < numAnalogReadings; i++) {

int s = analogRead(aPin);

majority[i] = s;

delay(random(5,9));

}

return findCandidate();

}

void setup() {

delay(1000);

randomSeed(analogRead(A0));

Serial.begin(9600);

pinMode(LED, OUTPUT);

Serial.println("Ready");

analogWrite(pwmOut, 0);

delay(1000);

Serial.println("time\tlight\tvalue");

int i = 0;

int fadeVal = 0;

do {

analogWrite(pwmOut, fadeVal);

delay(200);

sensorVal = multiAnalogRead(sensorPin); // analogRead(sensorPin);

sprintf(pout,"%d\t%d\t%d",i, fadeVal, sensorVal);

Serial.println(pout);

i++;

ledState = !(ledState);

digitalWrite(LED, ledState);

fadeVal += 5;

} while (fadeVal <= 255);

Serial.println("finished");

}

void loop() {

}

From the output, I was able to produce these graphs, remember that for the Common Emitter setup being used the voltage drops as the light increases, not quite getting the smooth response to light/time I was expecting.

I am not sure why I got these results, they were consistent and I suspect my test setup. Some more experimentation is needed, but for now I have run out of time.

Links and Sources

SFH3710 datasheet
TEPT4400 datasheet
Fairchild Semiconductors, Application Note AN-3005: Design Fundamentals for Phototransistor Circuits
Vishay Semiconductors, Application Note: Ambient Light Sensors – Circuit and Window Design
Sharp Optoelectronics Photodiode/Phototransistor Application Circuit
Using an IR phototransistor
ECE 4760: Final Project Image Scan using Phototransistor Array
Proximity-Sensing LEDs
Arduino’s AnalogWrite – Converting PWM to a Voltage
how to compute bias resistor for phototransistor

Arduino, Electronics, Hardware, Interesting

Controlling the Zoom H2n Audio Recorder with Arduino

17th April 2017 Karl

In Part One I covered the byte codes sent by the Zoom Remote Controller RC1 and decoded data sent over the wire to the remote from the Zoom H2n Recorder.

In this post I will be covering the use of an Arduino style micro-controller to decode the signals sent by the remote, then control the recorder. I have used a Tennsy 3.1 Arduino clone as this is a small controller with two additional hardware serial ports, works with 3.3volt logic, and a with the addition of a crystal and button battery a real-time clock.

Setup and Connections

The connections on the remotes four pin 2.5mm jack, with pin one being the tip:

Remote Receive – RX
Remote Transmit – TX
Ground
3.1V – Power

On the Teensy there are two hardware serial UARTs available in addition to that used by the USB port, UART2: Pin 9 (RX2), Pin 10 (TX2) and UART3: Pin 7 (RX3), Pin 8 (TX3). Serial data is sent at 2400 baud, 8 bits, no parity, 1 stop (8n1). The response data shown is for when the recorder is in XY Stereo mode (0x20, 0x21), different codes are returned when other recording modes are used, see the end of Part One for details.

Serial Monitor

This first chunk of code is for monitoring the outputs of the remote control and recorder. Connect Remote Receive – RX on the remote to RX2 – Pin 9 on the Teensy and Remote Transmit – TX to RX3 – Pin 7 and Ground to Ground on the Teensy. This program will output data received to the Arduino IDE’s serial monitor.

//written for a Teensy 3.x
#define MONITOR_LED 13
int incomingByte2 = 0;
int incomingByte3 = 0;
unsigned long nowMillis = 0;

void printByte(int p, int b) {
  char out[40];
  sprintf(out, "RX%d: %8lu\t0x%x\t%d",p,nowMillis,b,b);
  Serial.println(out);
}

void setup() {
  delay(1000);
  Serial.begin(9600);
  Serial.println("ready");

  // incoming data
  Serial2.begin(2400, SERIAL_8N1);  // Remote Receive - RX
  Serial3.begin(2400, SERIAL_8N1);  // Remote Transmit - TX

  pinMode(MONITOR_LED, OUTPUT);
  digitalWrite(MONITOR_LED, HIGH);
}

void loop() {

  nowMillis = millis();
  if (Serial2.available() > 0) {
    incomingByte2 = Serial2.read();
    printByte(2, incomingByte2);
  }

  if (Serial3.available() > 0) {
    incomingByte3 = Serial3.read();
    printByte(3, incomingByte3);   
  }
}

//written for a Teensy 3.x

#define MONITOR_LED 13

int incomingByte2 = 0;

int incomingByte3 = 0;

unsigned long nowMillis = 0;

void printByte(int p, int b) {

char out[40];

sprintf(out, "RX%d: %8lu\t0x%x\t%d",p,nowMillis,b,b);

Serial.println(out);

}

void setup() {

delay(1000);

Serial.begin(9600);

Serial.println("ready");

// incoming data

Serial2.begin(2400, SERIAL_8N1); // Remote Receive - RX

Serial3.begin(2400, SERIAL_8N1); // Remote Transmit - TX

pinMode(MONITOR_LED, OUTPUT);

digitalWrite(MONITOR_LED, HIGH);

}

void loop() {

nowMillis = millis();

if (Serial2.available() > 0) {

incomingByte2 = Serial2.read();

printByte(2, incomingByte2);

}

if (Serial3.available() > 0) {

incomingByte3 = Serial3.read();

printByte(3, incomingByte3);

}

The output is in four columns; the UART seeing activity, current milliseconds and the received data in hexadecimal and decimal values.

Taking Control – But Not Listening

Sending the command to the recorder blindly is quite straight forward, just send the bytes to the Remote Transmit – TX pin on the recorder (Zoom RX). This can be seen in the following, when run it starts the recorder recording for ten seconds. Connect: Remote TX to TX2 on the Teensy, Remote RX to RX2 and Ground to Ground.

//written for a Teensy 3.x
#define MONITOR_LED 13

// bytes to start and stop the recorder, a negative number is used as a delay
int record[5] = { 0x81, 0x0, -100, 0x80, 0x0 };  

void zoomTX(int d[], int len) {
    
    // show what is going to be done 
    for (int i = 0; i < len; i++) { 
      char out[40];
      if (d[i] < 0) {
        sprintf(out,"TX2: delay(%d)",abs(d[i]));
        Serial.println(out);        
      }
      else {
        sprintf(out, "TX2: %d\t0x%x", i, d[i]);        
        Serial.println(out);
      }      
    }

    // do the command
    for (int i = 0; i < len; i++) {  
      if (d[i] < 0) {
        delay(abs(d[i]));
      }
      else {
        Serial2.write(d[i]);
      }      
    }   
}

void setup() {

  delay(1000);
  Serial.begin(9600);
  Serial.println("ready");

  Serial2.begin(2400, SERIAL_8N1);  // connection to Zoom.

  pinMode(MONITOR_LED, OUTPUT);
  digitalWrite(MONITOR_LED, LOW);
  delay(2000);
  
  Serial.println("REC: start");
  zoomTX(record, sizeof(record)/sizeof(int));
  digitalWrite(MONITOR_LED, HIGH);

  Serial.println("-----------------");
  delay(10000); // wait ten seconds
   
  Serial.println("REC: stop");
  zoomTX(record, sizeof(record)/sizeof(int));
  digitalWrite(MONITOR_LED, LOW);

  Serial.println("-end-");
}

void loop() {
  // nothing to loop
}

//written for a Teensy 3.x

#define MONITOR_LED 13

// bytes to start and stop the recorder, a negative number is used as a delay

int record[5] = { 0x81, 0x0, -100, 0x80, 0x0 };

void zoomTX(int d[], int len) {

// show what is going to be done

for (int i = 0; i < len; i++) {

char out[40];

if (d[i] < 0) {

sprintf(out,"TX2: delay(%d)",abs(d[i]));

Serial.println(out);

}

else {

sprintf(out, "TX2: %d\t0x%x", i, d[i]);

Serial.println(out);

}

// do the command

for (int i = 0; i < len; i++) {

if (d[i] < 0) {

delay(abs(d[i]));

}

else {

Serial2.write(d[i]);

}

void setup() {

delay(1000);

Serial.begin(9600);

Serial.println("ready");

Serial2.begin(2400, SERIAL_8N1); // connection to Zoom.

pinMode(MONITOR_LED, OUTPUT);

digitalWrite(MONITOR_LED, LOW);

delay(2000);

Serial.println("REC: start");

zoomTX(record, sizeof(record)/sizeof(int));

digitalWrite(MONITOR_LED, HIGH);

Serial.println("-----------------");

delay(10000); // wait ten seconds

Serial.println("REC: stop");

zoomTX(record, sizeof(record)/sizeof(int));

digitalWrite(MONITOR_LED, LOW);

Serial.println("-end-");

}

void loop() {

// nothing to loop

}

Taking Control – And Listening for a Reply

The next stage is to have the Teensy control the Zoom and listen for a response from the recorder. Again, as before connect: Remote TX to TX2 on the Teensy, Remote RX to RX2 and Ground to Ground. For the demonstration I have added three buttons to act as the controller.

The following code needs more development work, I ran out of time, but I think gives a good starting point for further investigation. I have placed the commands for the remote in a structure, each command; record, pause and mark has four components, the command to transmit to the Zoom, the expected responses when starting and stopping and a flag to store the status.

//written for a Teensy 3.x

#define MONITOR_LED 13
#define RED_BTN 2
#define GRN_BTN 3
#define BLU_BTN 4

unsigned long nowMillis = 0;
unsigned long prevMillis = 0;
unsigned long buttonPressDelay = 400;
unsigned long serialTimeout = 8000; // it can take a few seconds for the zoom to start recording

struct ZOOMTX {
  int record[4][5] = { {0x81, 0x0, -100, 0x80, 0x0},   // Transmit command data - a minus number is used as a delay(xxx)
                       {0x20, 0x20, 0x21},             // Expected Response - Start (in XY Stereo mode)
                       {0x21, 0x21, 0x20},             // Response - Stop
                       {0} };                          // status: record[3][0] = 1: recording, 0: not recording
  int pause[4][5]  = { {0x80, 0x2, -100, 0x80, 0x0},
                       {0x21, 0x21, 0x20},
                       {0x20, 0x21},
                       {0} };
  int mark[4][5]   = { {0x80, 0x1, -100, 0x80, 0x0},
                       {0x20, 0x20},
                       {0x20, 0x20},
                       {0} };

  int noAction[2]  = { 0x20, 0x20 }; // this happens when pause is pressed while not recording. Response in XY Stereo mode
};

struct LED_MONITOR {
  const unsigned int onTime = 300;
  const unsigned int offTime = 500;
  unsigned long prevMillis = 0;
  unsigned int wait = onTime;
  boolean state = true;
};

ZOOMTX ZoomTX;
LED_MONITOR LEDmonitor;

void printByte(int p, int b) {

  char out[40];
  sprintf(out, "RX%d: %8lu\t0x%x\t%d", p, millis(), b, b);
  Serial.println(out);
}

boolean getButton(byte btn) {

  boolean b = digitalRead(btn);
  if (b == true) {
    while (digitalRead(btn) != b) {
      delay(5);    // wait until button release;
    }
    return true;
  }
  return false;
}

void zoomTransmit(int d[], int len) {

  for (int i = 0; i < len; i++) {
    char out[40];
    if (d[i] < 0) {
      sprintf(out, "TX2: delay(%d)", abs(d[i]));
      Serial.println(out);
    }
    else {
      sprintf(out, "TX2: %d\t0x%x", i, d[i]);
      Serial.println(out);
    }
  }

  for (int i = 0; i < len; i++) {
    if (d[i] < 0) {
      delay(abs(d[i]));
    }
    else {
      Serial2.write(d[i]);
    }
  }
}

// http://forum.arduino.cc/index.php?topic=5157.0
boolean arrayCompare(int *a, int *b, int len_a, int len_b) {
  int n;
  if (len_a != len_b) {
    return false;
  }
  for (n = 0; n < len_a; n++) {
    if (a[n] != b[n]) {
      return false;
    }
  }
  return true;
}

int arrayLen(int a[5]) {
  int c=0;
  for (int n = 0; n < 5; n++) {
    if (a[n] == 0) {
      break;      
    }
    c++;
  }
  return c;
}

boolean zoomCommand(int cmd[4][5]) {

  int responseBytes[5] = {0};  // for incoming serial data
  unsigned long serialNow = millis();
  int expectedResponse[3] = {0}; 
  int responseLen = 0;
  if (cmd[3][0] == 0) {  // copy the expected response into expectedResponse
    Serial.println("start");
    memcpy(expectedResponse, cmd[1], sizeof(cmd[1])); // expected start response
    responseLen = arrayLen(cmd[1]);
  }
  else {
    Serial.println("stop");
    memcpy(expectedResponse, cmd[2], sizeof(cmd[2])); // expected stop response
    responseLen = arrayLen(cmd[2]);
  }

  // clear the incoming serial2 buffer
  while(Serial2.available()) {
    Serial2.read();
  }
  
  // send the command to the zoom    
  zoomTransmit(cmd[0], sizeof(cmd[0]) / sizeof(int)); 
  
  // listen for a response
  while ((Serial2.available() > 0 && Serial2.available() < responseLen) && ((millis() - serialNow) < serialTimeout))
  {  } // listen for responseLen bytes or until serialTimeout
  
  if (Serial2.available() == 2) {  // only two bytes received?
    for (int n = 0; n < 2; n++) {
      responseBytes[n] = Serial2.read();
      printByte(2, responseBytes[n]);
    }
    if (arrayCompare(responseBytes, expectedResponse, 2, 2)) { 
      Serial.println("RX: OK - Acknowledged! (two bytes)"); // mark has a two byte response
      return true;
    }
    
    if (arrayCompare(responseBytes, ZoomTX.noAction, 2, 2)) {
      Serial.println("RX: no action data received - Zoom not in the state we thought it was?");
    }
    else {
      Serial.println("RX: did not understand the response - two bytes"); // probably not in XY Stereo mode?  
    }
    return false;
  }
  else {  // three or more bytes
    for (int n = 0; n < 3; n++) {   // check the first three
      responseBytes[n] = Serial2.read();
      printByte(2, responseBytes[n]);
    }
    if (arrayCompare(responseBytes, expectedResponse, 3, 3) == true) {
      Serial.println("RX: OK - Acknowledged!");
      return true;
    }
    else {
      Serial.println("RX: did not understand the response - three bytes"); // probably not in XY Stereo mode?
    }
  }  
  return false;
}

// https://www.baldengineer.com/millis-ind-on-off-times.html
void toggleMoitorLEDstate(unsigned long n) {

  if ((unsigned long)(n - LEDmonitor.prevMillis) >= LEDmonitor.wait) {
    if (LEDmonitor.state) {
      LEDmonitor.wait = LEDmonitor.offTime;         
    }
    else {
      LEDmonitor.wait = LEDmonitor.onTime; 
    }  
    LEDmonitor.state = !(LEDmonitor.state);
    LEDmonitor.prevMillis = n;
  }
}

void setup() {
  delay(1000);
  Serial.begin(9600);
  Serial.println("ready");

  Serial2.begin(2400, SERIAL_8N1); // zoom connection

  pinMode(MONITOR_LED, OUTPUT);
  pinMode(RED_BTN, INPUT);
  pinMode(GRN_BTN, INPUT);
  pinMode(BLU_BTN, INPUT);
  digitalWrite(MONITOR_LED, LOW);
}

void loop() {

  nowMillis = millis();

  if (getButton(RED_BTN) && nowMillis >= (prevMillis + buttonPressDelay)) {
    Serial.print("RECORD: ");
    if (zoomCommand(ZoomTX.record)) {
      if (ZoomTX.record[3][0] == 0) {
        digitalWrite(MONITOR_LED, HIGH);
        ZoomTX.record[3][0] = 1;  // recording started
      }
      else {
        digitalWrite(MONITOR_LED, LOW);
        ZoomTX.record[3][0] = 0;  // recording stopped
        ZoomTX.pause[3][0] = 0;   // recording now not paused (just in case)
      }
    }
    else {
       Serial.println("RECORD COMMAND FAILED!");
    }
    prevMillis = nowMillis;
  }

  // pause only works when recording
  if (getButton(GRN_BTN) && ZoomTX.record[3][0] == 1 && nowMillis >= (prevMillis + buttonPressDelay)) {
    Serial.print("PAUSE: ");
    if (zoomCommand(ZoomTX.pause)) {
      ZoomTX.pause[3][0] = !(ZoomTX.pause[3][0]); // toggle the pause status
      digitalWrite(MONITOR_LED, HIGH);
    }
    else {
       Serial.println("PAUSE COMMAND FAILED!"); // probably not recording, or not recording in XY Stereo
    }
    prevMillis = nowMillis;
  }

  if (getButton(BLU_BTN) && ZoomTX.record[3][0] == 1 && nowMillis >= (prevMillis + buttonPressDelay)) {
    Serial.print("MARK: ");
    if (zoomCommand(ZoomTX.mark)) {
      Serial.println("recording marked");
    }
    else {
       Serial.println("PAUSE COMMAND FAILED!"); // probably not recording, or not recording in XY Stereo
    }
    prevMillis = nowMillis;
  }
    
  // blink the LED while paused
  if (ZoomTX.pause[3][0] == 1) {
      digitalWrite(MONITOR_LED, LEDmonitor.state);
      toggleMoitorLEDstate(nowMillis);    
  }

}

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

//written for a Teensy 3.x

#define MONITOR_LED 13

#define RED_BTN 2

#define GRN_BTN 3

#define BLU_BTN 4

unsigned long nowMillis = 0;

unsigned long prevMillis = 0;

unsigned long buttonPressDelay = 400;

unsigned long serialTimeout = 8000; // it can take a few seconds for the zoom to start recording

struct ZOOMTX {

int record[4][5] = { {0x81, 0x0, -100, 0x80, 0x0}, // Transmit command data - a minus number is used as a delay(xxx)

{0x20, 0x20, 0x21}, // Expected Response - Start (in XY Stereo mode)

{0x21, 0x21, 0x20}, // Response - Stop

{0} }; // status: record[3][0] = 1: recording, 0: not recording

int pause[4][5] = { {0x80, 0x2, -100, 0x80, 0x0},

{0x21, 0x21, 0x20},

{0x20, 0x21},

{0} };

int mark[4][5] = { {0x80, 0x1, -100, 0x80, 0x0},

{0x20, 0x20},

{0} };

int noAction[2] = { 0x20, 0x20 }; // this happens when pause is pressed while not recording. Response in XY Stereo mode

};

struct LED_MONITOR {

const unsigned int onTime = 300;

const unsigned int offTime = 500;

unsigned long prevMillis = 0;

unsigned int wait = onTime;

boolean state = true;

};

ZOOMTX ZoomTX;

LED_MONITOR LEDmonitor;

void printByte(int p, int b) {

char out[40];

sprintf(out, "RX%d: %8lu\t0x%x\t%d", p, millis(), b, b);

Serial.println(out);

}

boolean getButton(byte btn) {

boolean b = digitalRead(btn);

if (b == true) {

while (digitalRead(btn) != b) {

delay(5); // wait until button release;

}

return true;

}

return false;

}

void zoomTransmit(int d[], int len) {

for (int i = 0; i < len; i++) {

char out[40];

if (d[i] < 0) {

sprintf(out, "TX2: delay(%d)", abs(d[i]));

Serial.println(out);

}

else {

sprintf(out, "TX2: %d\t0x%x", i, d[i]);

Serial.println(out);

}

for (int i = 0; i < len; i++) {

if (d[i] < 0) {

delay(abs(d[i]));

}

else {

Serial2.write(d[i]);

}

// http://forum.arduino.cc/index.php?topic=5157.0

boolean arrayCompare(int *a, int *b, int len_a, int len_b) {

int n;

if (len_a != len_b) {

return false;

}

for (n = 0; n < len_a; n++) {

if (a[n] != b[n]) {

return false;

}

return true;

}

int arrayLen(int a[5]) {

int c=0;

for (int n = 0; n < 5; n++) {

if (a[n] == 0) {

break;

}

c++;

}

return c;

}

boolean zoomCommand(int cmd[4][5]) {

int responseBytes[5] = {0}; // for incoming serial data

unsigned long serialNow = millis();

int expectedResponse[3] = {0};

int responseLen = 0;

if (cmd[3][0] == 0) { // copy the expected response into expectedResponse

Serial.println("start");

memcpy(expectedResponse, cmd[1], sizeof(cmd[1])); // expected start response

responseLen = arrayLen(cmd[1]);

}

else {

Serial.println("stop");

memcpy(expectedResponse, cmd[2], sizeof(cmd[2])); // expected stop response

responseLen = arrayLen(cmd[2]);

}

// clear the incoming serial2 buffer

while(Serial2.available()) {

Serial2.read();

}

// send the command to the zoom

zoomTransmit(cmd[0], sizeof(cmd[0]) / sizeof(int));

// listen for a response

while ((Serial2.available() > 0 && Serial2.available() < responseLen) && ((millis() - serialNow) < serialTimeout))

{ } // listen for responseLen bytes or until serialTimeout

if (Serial2.available() == 2) { // only two bytes received?

for (int n = 0; n < 2; n++) {

responseBytes[n] = Serial2.read();

printByte(2, responseBytes[n]);

}

if (arrayCompare(responseBytes, expectedResponse, 2, 2)) {

Serial.println("RX: OK - Acknowledged! (two bytes)"); // mark has a two byte response

return true;

}

if (arrayCompare(responseBytes, ZoomTX.noAction, 2, 2)) {

Serial.println("RX: no action data received - Zoom not in the state we thought it was?");

}

else {

Serial.println("RX: did not understand the response - two bytes"); // probably not in XY Stereo mode?

}

return false;

}

else { // three or more bytes

for (int n = 0; n < 3; n++) { // check the first three

responseBytes[n] = Serial2.read();

printByte(2, responseBytes[n]);

}

if (arrayCompare(responseBytes, expectedResponse, 3, 3) == true) {

Serial.println("RX: OK - Acknowledged!");

return true;

}

else {

Serial.println("RX: did not understand the response - three bytes"); // probably not in XY Stereo mode?

}

return false;

}

// https://www.baldengineer.com/millis-ind-on-off-times.html

void toggleMoitorLEDstate(unsigned long n) {

if ((unsigned long)(n - LEDmonitor.prevMillis) >= LEDmonitor.wait) {

if (LEDmonitor.state) {

LEDmonitor.wait = LEDmonitor.offTime;

}

else {

LEDmonitor.wait = LEDmonitor.onTime;

}

LEDmonitor.state = !(LEDmonitor.state);

LEDmonitor.prevMillis = n;

}

void setup() {

delay(1000);

Serial.begin(9600);

Serial.println("ready");

Serial2.begin(2400, SERIAL_8N1); // zoom connection

pinMode(MONITOR_LED, OUTPUT);

pinMode(RED_BTN, INPUT);

pinMode(GRN_BTN, INPUT);

pinMode(BLU_BTN, INPUT);

digitalWrite(MONITOR_LED, LOW);

}

void loop() {

nowMillis = millis();

if (getButton(RED_BTN) && nowMillis >= (prevMillis + buttonPressDelay)) {

Serial.print("RECORD: ");

if (zoomCommand(ZoomTX.record)) {

if (ZoomTX.record[3][0] == 0) {

digitalWrite(MONITOR_LED, HIGH);

ZoomTX.record[3][0] = 1; // recording started

}

else {

digitalWrite(MONITOR_LED, LOW);

ZoomTX.record[3][0] = 0; // recording stopped

ZoomTX.pause[3][0] = 0; // recording now not paused (just in case)

}

else {

Serial.println("RECORD COMMAND FAILED!");

}

prevMillis = nowMillis;

}

// pause only works when recording

if (getButton(GRN_BTN) && ZoomTX.record[3][0] == 1 && nowMillis >= (prevMillis + buttonPressDelay)) {

Serial.print("PAUSE: ");

if (zoomCommand(ZoomTX.pause)) {

ZoomTX.pause[3][0] = !(ZoomTX.pause[3][0]); // toggle the pause status

digitalWrite(MONITOR_LED, HIGH);

}

else {

Serial.println("PAUSE COMMAND FAILED!"); // probably not recording, or not recording in XY Stereo

}

prevMillis = nowMillis;

}

if (getButton(BLU_BTN) && ZoomTX.record[3][0] == 1 && nowMillis >= (prevMillis + buttonPressDelay)) {

Serial.print("MARK: ");

if (zoomCommand(ZoomTX.mark)) {

Serial.println("recording marked");

}

else {

Serial.println("PAUSE COMMAND FAILED!"); // probably not recording, or not recording in XY Stereo

}

prevMillis = nowMillis;

}

// blink the LED while paused

if (ZoomTX.pause[3][0] == 1) {

digitalWrite(MONITOR_LED, LEDmonitor.state);

toggleMoitorLEDstate(nowMillis);

}

There is a problem when resuming from pause, because the Zoom sends codes to flash the LED on the remote this can pick up the wrong pair of bytes; such as 0x21 0x21 instead of the expected 0x20 0x21.

I expect to be revisiting this, adding a timer function plus external battery for long running. I’m not sure how useful listening for a response is, sending the record command toggle on its own seems fairly robust without the need to check.

Links and Sources

Arduino, Electronics, Hardware, Interesting

Hacking the Zoom H2n Remote Control

14th April 2017 Karl

The Zoom H2n is a portable sound recorder looking like an old fashioned microphone it is a handheld device that provides an assortment of stereo and surround recording modes, it records onto an SD card in MP3 or WAV format with options for various bitrates and frequencies. The unit is powered internally by two AA batteries and can also be powered from the USB port. The recorder I am experimenting on has firmware version 2.00 installed.

A not at all contrived image of the Zoom H2n Portable Recorder

The Zoom Remote Controller RC2 is a wired four pin 2.5mm jack plug connection, this remote has three buttons: record, mark, and pause there is also an LED to show when the H2n is recording. It is purchased separately from the recorder and only appears to be available bundled in an accessory pack. It looks difficult to take apart without leaving some damage, and this may not be necessary for decoding.

In this post I am looking to see how the remote works and find what control method it employs so in Part Two I can use an Arduino style micro-controller to provide an external trigger such as for timed recordings.

Setup for Testing

For testing I have made a breakout lead, this is essentially an extension cable split in half with a couple of molex style connectors allowing me to plug it into a breadboard. With this I have found the cable has the following connections, with pin one being the tip of the 2.5mm jack plug:

Remote Receive – RX
Remote Transmit – TX
Ground
3.1V – Power

When checking with a multimeter I found continuity from the negative of the left battery (on the Mic Gain side) to pin three, ground, of the jack, there is also a connection between the positive of the right-hand battery to pin one of the jack but on the multimeter in diode mode there looks to be a capacitor, the voltage rises until no apparent connection is indicated. With no activity on the recorder the RX and TX pins show ~2.7 volts.

Determining the RX and TX pins turned out to be straightforward. When you press the record button after a moment the recording LED lights up, on the oscilloscope I can see three different square wave patterns for the three different buttons on the TX pin and a single type of square wave on RX to light the LED. The following images show the signal for the record button then that sent in response to to light the LED.

Signal sent by the remote when Record pressed

Signal sent by the Zoom recorder to light the LED in the remote

Also when buttons are pressed on the recorder data is seen on the RX line. For a more detailed examination I will need to break out the logic analyser.

Signal Analysis

Following some research where the remote for a Zoom H4n was examined, I set both channels being used on the logic analyser to the following:

Protocol: UART
2400 baud, 8 bits, no parity, 1 stop (8n1)
Bit Order: LSB first, inverted logic: No

Decoding of the first part of the stop recording command

First I decoded the buttons on the remote with the trigger on the logic analyser set to falling edge on the Remote TX line. On TX there is a pause between the two pairs of command bytes which appears to be the length of time the button was pressed, around 350-500ms, there is also a pause between bytes in the RX response, the value of the response changes depending on which recording mode you are in, those shown below are when the recorder is in XY Stereo:

Record Start
TX:	0x81 0x0	~	0x80 0x0
RX:	0x20	1.85s	0x20 0x21	record LED on
Record Stop
TX:	0x81 0x0	~	0x80 0x0
RX:	0x21 0x21 0x20	1.9s	0x20 0x20	record LED off
Pause (while recording)
TX:	0x80 0x2	~	0x80 0x0
RX:	0x21	51ms	0x21 0x20	then this repeats
		492ms	0x20 0x21	to flash the LED
		492ms	0x21 0x20	until pause is pressed again
Resume from Pause
TX:	0x80 0x2	~	0x80 0x0
RX:	0x21 0x21			LED on
Mark
TX:	0x80 0x1	~	0x80 0x0
RX:	0x21	492ms	0x20 0x21	LED on

I was also able to capture the following activity sent to the remote when various buttons were pressed on the recorder itself with the recorder in XY Stereo mode. Other models of the recorders made by Zoom have more advanced remotes, such as the RC4 as featured in this hack of the H4n. I suspect they would work on this machine too. This time I set the logic analyser to trigger with a falling edge on Remote RX. I think the 0x20 code is used to indicate the display illumination has been turned off. I saw activity on all buttons except the Mic Gain knob.

Power On – Without remote attached
TX:	Lots of random activity
RX:	0x10	400ms	0x80 0x81
		1.2s	0x10 0x0 0x80 0x0
		140ms	0x0 0x0 0x80 0x80 0x0
		~2ms	0x0 0x80 0x0 0x0 0x80 0x0
Power On – With remote attached
TX:	0x0	five pulses 30ms apart
		30ms	0x0 0xA1 0x80 0x0 0xA1
RX:	following pulses on TX		0x80 0x81 0x80 0x10
		1.2s	0x10 0x0
		148ms	0x0 0x0
		~4ms	0x0 0x0 0x0
Record Start
RX:	0x20	20ms	0x20 0x21	LED on
Record Stop
RX:	0x21 0x21 0x21 0x20	~	0x20
		~283ms	0x20 0x20	LED off
Menu \ Home – Into Menu
RX:	0x20 0x20 0x0
Exit from Menu
RX:	0x20	45ms	0x20
Play Switch: Up/Down/Press
RX:	0x20	55ms	0x20
Clipping detect (tapping the microphone with a pen)
RX:	0x10 0x2	56ms	0x2
		59ms	0x10
		60ms	0x10
		354ms	0x10
Volume: Up and Down
RX:	0x20
Recording Mode Change: 4 channel surround
RX:	0x10 0x10 0x30	14ms	0x30 0x30
		122ms	0x34
		60ms	0x30
		60ms	0x30
Recording Mode Change: XY Stereo
RX:	0x30 0x30 0x20	216ms	0x20
Recording Mode Change: 2 channel surround
RX:	0x20 0x20 0x30 0x30	18ms	0x30
		148ms	0x30
		164ms	0x30 0x6
		56ms	0x14 0x30
		477ms	0x30
Recording Mode Change: MS Stereo
RX:	0x30 0x30 0x10	170ms	0x10
		50ms	0x12

I think these response codes are to light up various LED’s on the more advanced Zoom RC4 remote, this suggests that other remotes would work in this recorder.

The following table shows the response codes given with different microphone configurations when record is clicked to start recording:

TX:	0x81 0x0 ~100ms delay 0x80 0x0
XY Stereo:	0x20 750ms delay 0x20 0x21
2 Channel Surround:	0x30 750ms delay 0x30 0x31
MS Stereo:	0x10 750ms delay 0x10 0x11
4 Channel Surround:	0x30 750ms delay 0x30 0x31

In Part Two I will be covering the use of a Arduino style micro-controller as an alternative remote control.

Links and Sources

Manufacturers Page: Zoom H2n
Hacking the Zoom H4n remote
Logic Analyser: https://www.ikalogic.com/scanaplus/

Installing RP2040 Support for Platform IO

Initializing the LoRa Radio

Power Supply

Driving the Display

Rotary Switch

Software

Links and Sources

Circuitry

Software

Links and Sources

Opening it up

Flash Connection

Microcontroller Connections

Using a Logic Analyser

Looking at the A7105 Transceiver

How the A7105 organises data

Examining the A7105 data

Power On

Shutter Press

Links and Sources

Connecting

Phototransistor Modes

Practical Experiments

Links and Sources

Setup and Connections

Serial Monitor

Taking Control – But Not Listening

Taking Control – And Listening for a Reply

Links and Sources

Setup for Testing

Signal Analysis

Links and Sources

COMPUTERS, ROBOTS AND PHOTOGRAPHY