There definitely seems to be some issue with the QN command using the API getSerialNumber
I am running a single servo at 500000 baud and I do get some errors like this…
below it seems to report the firmware number
#0D1200#0LED5#0QD#0QWR#0QC#0QV#0QT#0QN#0QF
1200,1100,0,57,10876,386,368,368
in the next increment it is blank
#0D1300#0LED5#0QD#0QWR#0QC#0QV#0QT#0QN#0QF
1300,0,1,59,10876,386,368
then in the next one it has errors…
#0D1400#0LED5#0QD#0QWR#0QC#0QV#0QT#0QN#0QF
1400,1300,0,62,10876,386,000L⸮⸮⸮⸮⸮000000000,0
Also very rarely the QN reports back the serial as all 0’s but then the QF command fails
#0D500#0QD#0QWR#0QC#0QV#0QT#0QN#0QF
500,601,0,55,10873,386,000000000000000000,0
then it goes back to reporting 368.
#0D400#0QD#0QWR#0QC#0QV#0QT#0QN#0QF
400,500,0,52,10875,387,368,368
I am running the simple position increments in 100 form 0 - 1800 and back and after each increment i read the position, current , voltage… temperature serial and the firmware version.
But then instead of using the API if I run my snippet below to get the Serial number it happily runs everytime…
Serial.write("#0QN\r");
delay(250);
if ( Serial.available())
{
while( ch != ‘\r’)
{
ch = Serial.read();
Serial.print(ch);
}
}
Althought still says the serial number is all 0’s 
#0QN
*0QN000000000000000000
is it possible the underlying genericread_blocking_str function is slow for specifically the QN commands response or does not block the next command’s response to overwrite the data in the serial buffer ? Jut thinking out loud… because I see the data for the FW in the QN’s response…
