Troubleshooting

These are the problems this instrument actually produces, not a generic list. Most of them are the shared analog path or the wireless link behaving exactly as designed.

The board connects over BLE but never replies

The BLE connection is between your host and the HM-10 module. It says nothing about whether the microcontroller behind that module is running or listening at the right speed. Two causes account for nearly all of these:

The MCU is not running. The module will advertise and accept a connection regardless. Check power at the board, not just that a device appeared in the scan list.

The module is not at 115200. The firmware runs its UART at 115200 and only 115200; there is no rate negotiation and no fallback. The HM-10 stores its own rate in its own non-volatile memory, so a module that was configured to anything else will pass bytes the ATmega cannot parse. The symptom is a connection that succeeds while every command is ignored.

What to do: this cannot be fixed from the board — the ATmega has no way to move, and no command you send will be understood. The module itself has to be set back to 115200, which is a module configuration task rather than an instrument one. If the board was working before and stopped after a firmware flash, suspect the MCU rather than the rate: the flash does not touch the module’s setting.

A control is greyed out with an explanation

This is intentional and it is not a bug. The app mirrors the firmware’s own restrictions rather than letting you send a command that will come back as an error. The explanatory text tells you which mode or channel allows the control, and there is a one-click switch to get there.

Almost every one of these traces back to the shared analog path: the oscilloscope borrows CH1’s gain pack and CH1’s signal DAC, so it cannot coexist with CH1 generating, and the 16-bit SAR cannot coexist with any synthesiser running. See Why the Modes Exist.

CH2’s “amplitude” changes when I change CH1’s offset

You are in CH1 Generator mode, where CH2’s chain is CH1’s offset hardware. The offset DAC and the ba/bg potentiometer pack are not idle in this mode — they are producing CH1’s DC offset. Moving CH1’s offset moves those wipers, because they are the same two wipers CH2’s amplitude control drives in other modes.

What to do: nothing. Current builds disable the CH2 amplitude controls in this mode and explain why. If you are driving the board by hand over the protocol, be aware that ba and bg mean “CH1’s offset” here.

Amplitude came back at maximum after reflashing

Expected, and worth taking seriously.

The X9C digital potentiometers have no read-back path. The firmware cannot ask them where their wipers are — it drives them to a known end stop at boot and then restores the saved positions from EEPROM. A chip erase wipes those saved positions, and the build process flashes with a chip erase. With nothing to restore, the wipers stay at position 99: 15.15 Vpp.

Set your amplitude before connecting anything sensitive to a freshly flashed board. This is the single most likely way to damage something with this instrument.

Captures time out at large sample counts

Throughput is limited by the wireless link, not by the converters. In the full-precision ASCII format the link sustains roughly 1.1 k samples per second, so a large enough burst cannot finish inside the timeout.

What to do, in order of effort:

  1. Reduce the sample count.
  2. Switch the capture format to the compact binary tier, or to AUTO — AUTO picks the highest precision that can still finish the burst in time.

The link rate is fixed at 115200 and is not something you can raise; see Link and Throughput.

A SAR capture returns an error

The 16-bit SAR is available in Oscilloscope mode only. Its comparison reference is CH1’s signal DAC, and the SAR routine walks that DAC bit by bit — which it cannot do while a synthesiser is also writing to it. In any mode where the DDS runs, o and os reply -4.

What to do: switch to Oscilloscope mode, or use the internal 10-bit ADC (oi), which touches no DAC and works in CH2 Generator + Scope mode.

A CH1 command returns an error

Error -3 means the command is CH1-only and the active channel is CH2. CH1’s frequency, waveform, phase and duty commands are guarded by the active channel; CH2’s equivalents are not. Select CH1 first.

The offset command is refused

Error -4 on the static offset command means the offset DAC is currently generating a waveform rather than holding a level. That is the case in Dual Independent mode and in CH2 Generator + Scope mode.

What to do: in Dual mode, offset has to come out of digital headroom and therefore competes with amplitude — reduce the amplitude to open up offset range. If you need the full ±7.58 V offset, use a single-channel generator mode, where a dedicated chain provides it.

The trace is flat-topped

Either the generator output is hitting its ±10 V rail, or the scope input is exceeding the converter’s ±2.5 V node full scale at the current gain.

For the output: amplitude and offset share one headroom budget and the rail is hard. Check the offset — a modest offset can still push the positive peak into the rail once amplitude is added. Watch the app’s REACHABLE readout.

For the input: reduce the gain, or run Autoset, which searches upward from minimum gain and will not overdrive the comparator on the way.

The trace is unstable in Normal trigger mode

Triggering is applied after capture, to a buffer that has already been recorded. There is no hardware trigger circuit. If the trigger condition is not present in a given buffer, Normal mode has nothing to align to and the display will not update.

What to do: adjust the trigger level, or capture more samples per burst so each buffer covers more cycles of the signal. If you are trying to catch a one-shot event, this instrument cannot reliably do it — see Triggering and Autoset.

The output is live on a board I thought was off

The output gate relays K2 and K3 mute when energised and pass signal when de-energised. A board that has lost power, crashed, or reset falls back to passing signal.

What to do: disconnect the load rather than relying on the board’s state. This is a property of the hardware, not a fault, and it will not be fixed by firmware.

Updated · Full project report (PDF)