Firmware Bug Tracker

This page lists all bugs, as well as potential work-arounds, which have been found to date, for each Q8 firmware version. To upgrade to the latest firmware, contact us at [email protected]. If you find a bug, please report it, either by email, or in the comments below. v2.3.1 All channel write commands (e.g. v0=5.0, i3=15.0)…

By

min read

Share

a stag beetle on a pink flower in macro photography

pexels-photo-8803045

This page lists all bugs, as well as potential work-arounds, which have been found to date, for each Q8 firmware version. To upgrade to the latest firmware, contact us at [email protected]. If you find a bug, please report it, either by email, or in the comments below.


v2.3.1

  1. All channel write commands (e.g. v0=5.0, i3=15.0) return successfully, but sometimes fail to update the output on certain modules.
    • This is caused by an over-optimistic communications rate with the on-board DAC causing the DAC to occasionally ignore commands.
    • Work-around: To be sure the output is truly updated, either read back the voltage or current to confirm the change, or simply send the set command more than once (in our testing, 3 consecutive set commands give a 1:1000000 failure probability).

v2.1.1

  1. All channel read commands (e.g. vall?) sometimes return corrupted or out-of-order responses
    • This is the result of a race condition in these commands, where downstream data can sometimes beat local data into the upstream transmit buffer.
    • Work-around: If read out is mission-critical, avoid usage of *all? commands, instead looping through a read of each channel individually. In most cases, the output can be simply discarded if a syntax error is discovered, preserving the very fast read of the *all?-type commands.
  2. Software current control response is slow (Q8 only)
    • This occurs when multiple channel outputs are controlled by ‘current’. Since the Q8 implements a software control loop, as more channels are controlled by current, this loop slows down and negatively affects the transient performance.
    • Work-around: If your application permits, is to set unused channels to voltage-control mode (e.g. if channel 7 is unused, set V7=0, rather than I7=0). If your loads are mostly static and independent, then you can use current control to find the voltage operating point, then switch over to voltage control.
    • Work-around: The feedback loop includes a digital filter, which you can adjust using the CCFN parameter (readable and writable). Smaller numbers give a faster response (default CCFN=32). Test the stability for a given CCFN and for your desired minimum number of current-controlled channels (per Q8 module). Small CCFN will tend to cause oscillations if only a few channels are in current control mode (see v1.64.1 bug 1). CCFN values must be powers of 2.

v1.64.1

  1. Output voltage oscillates in current control mode when current averaging is enabled.
    • This bug results from interaction between the smoothed current measurement time, and the voltage settling time. Oscillation results. The outputs remain protected from overvoltage situations, provided VMAX is set on the respective channel.
    • Work-around: If current control is desired, set ADCN=1. Further, ensure that VMAX is set for relevant channels for extra protection.

v1.63

  1. Daisy chained devices return faulty data when requested.
    • Work-around: None.

v1.62

  1. Serial communications freezes up after extended use.
    • This bug results from a serial framing error which happens very sporadically, roughly once in every 150,000 bytes transmitted.
    • Work-around: Power cycle the device to restore normal operation.
  2. Serial character is occasionally misinterpreted.
    • This bug arises from a serial buffer overflow, when the Q8 firmware cannot parse instruction characters faster than they are received. Like bug #1, it happens very occasionally.
    • Work-around: Handle unknown command/parameter/port errors (E00, E10, E11, E12), retransmit instructions upon receiving one of these. When writing values (e.g. V[ch]=[val]), read them back after writing to check they have been successfully taken in (e.g. V[ch]?).

v1.60

  1. Strange behaviour results with slow-starting power supplies.
      • This bug arises from a corruption of the NVM due to a start-up routine write which is interrupted by a power failure. When this repeats, the NVM can become entirely corrupted.
      • Work-around: Re-initialise the NVM using the command sequence
        SAFE=0\n NVMALL=0\n. Calibration data and device ID will be deleted. Reintroduce these using  the VCAL[ch], ICAL[ch], and ID=[decimal number] commands, following instructions in the manual.

Share


❄️ Winter Holiday Closure

We will be pausing operations to celebrate the holiday season, starting Friday 20 December 2024, and resuming business as usual on Monday 6 January 2025. We hope you too can take time to enjoy the season and to celebrate the coming new year.