Hi Farhan;
Sorry - I was not very clear with my previous email. The potential software bug is in the Arduino .ino code for the attiny85 microcontroller that's new to the sbitx V2 hardware.
The attiny85 Arduino code executes in a loop that reads the forward and reflected power values from the two ADC channels, then assigns those values to four bytes in the message[] variable array, one byte at a time, like so:
? delay(100);
? fwd = analogRead(A2);
? ref = analogRead(A3);
? message[0] = fwd & 0xff;
? message[1] = fwd >> 8;
? message[2] = ref & 0xff;
? message[3] = ref >> 8;
This loop was executing every 100 mS, but github shows that you just changed the delay call in that loop from delay(100) to delay(2) so the loop is now repeating approximately every 2 milliseconds. That change increases the probability that the attiny85 will be in the middle of assigning values to the message[] array when it gets interrupted by an i2c request from the pi,
Your arduino .ino code for the attiny85 also sets up an interrupt with a statement in the setup() section:
?? Wire.onRequest(requestEvent); // register event
This code enables an interrupt that will occur when an i2c event is received. The attiny85 will stop whatever it is doing and branch to the requestEvent() interrupt service routine. This means that the loop() code will be interrupted whenever an i2c event occurs. That interrupt code services the i2c request and provides the forward and reflected power readings back to the pi. The data being sent back to the pi is contained in the message[] array.
If the attiny85 code execution point is in the middle of updating any of the message[] variables when that i2c interrupt occurs, the array will have some values from the latest adc() read function call and some values from the previous adc() read function call when those values are sent back to the sbitx app on the pi.
For example, if the previous ADC() reading was 0x01 0x00 and the new reading was one count less 0x00 0xFF, and the i2c interrupt occurred while the code was in the middle of updating these two bytes, the LSB could get updated to 0xFF then before the MSB got updated to 0x00, the interrupt would get called, and the bytes that get passed back to the pi would be 0x01 0xFF, which would be significantly wrong.
I think the simplest way to prevent this problem from occurring is to change the attiny85 Arduino .ino code as shown below, bracketing the array writes with noInterrupts() and interrupts():
? noInterrupts();
? message[0] = fwd & 0xff;
? message[1] = fwd >> 8;
? message[2] = ref & 0xff;
? message[3] = ref >> 8;
? interrupts();
73; Steve, N3SB
