|
Hi Farhan;
Looks like you are tweaking on the swr_bridge.ino program that lives in the attiny85. It looks like there could be a possibility that the message[] variable assignments, which occur in a fast loop, could get interrupted mid-stream by an i2c request from the pi, which would corrupt the forward and reverse power readings that are sent back to the pi.
You may want to set a flag in the requestEvent() function, which is then used in the main loop to get an update from the ADC channels, make the message[] variable assignments, then clear that flag and just wait for the next i2c read request to come in.
An alternative would be to block interrupts while making the message[] variable assignments, but this could impact the i2c code.
Note: I haven't built the Power/SWR sensor circuit for my DE, but I am collecting the parts.
73; Steve, N3SB
|
Steve, The i2c bus is bit banged out in our own. As such it is used for si5351, the real time clock and the swr bridge. The rtc is read just once at the begining of the program. The si5351 is written only when you change the frequency and the swr bridge is read only during transmit.? The clash between the si5351 and swr is highly unlikely. But a flag to show it is busy is a worthwhile addition all the same. - f
On Tue, May 2, 2023, 6:43 PM Steve Beckman < n3sb@...> wrote: Hi Farhan;
Looks like you are tweaking on the swr_bridge.ino program that lives in the attiny85. It looks like there could be a possibility that the message[] variable assignments, which occur in a fast loop, could get interrupted mid-stream by an i2c request from the pi, which would corrupt the forward and reverse power readings that are sent back to the pi.
You may want to set a flag in the requestEvent() function, which is then used in the main loop to get an update from the ADC channels, make the message[] variable assignments, then clear that flag and just wait for the next i2c read request to come in.
An alternative would be to block interrupts while making the message[] variable assignments, but this could impact the i2c code.
Note: I haven't built the Power/SWR sensor circuit for my DE, but I am collecting the parts.
73; Steve, N3SB
|
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
|
Fabulous, I will roll this in. Or better?yet, can you send me a pull?
On Tue, May 2, 2023, 9:33 PM Steve Beckman < n3sb@...> wrote: 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
|
Farhan - can do. I currently don't have a way to test this change, however. I would not want the fix to cause more problems than the potential issue.
73; Steve, N3SB
|
Correct me if I'm wrong, but better disable the interrupts just in the message writing itself. I created the PR 29. Here is the diff:
Rafael
toggle quoted message
Show quoted text
On 5/2/23 19:36, Ashhar Farhan wrote: Fabulous, I will roll this in. Or better?yet, can you send me a pull?
On Tue, May 2, 2023, 9:33 PM Steve Beckman <n3sb@...> wrote:
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
|
btw, the rationale for this I just wrote - we don't want the I2C response to be delayed (IO is not the fast operation in the MCU... and we already have problems enough with bit-banging), but having a consistent read 1ms late (just exaggerating here) in the worst case is not a big issue.
I glue the diff here:
? delay(2);
? fwd = analogRead(A2);
? ref = analogRead(A3);
+? noInterrupts();
? message[0] = fwd & 0xff;
? message[1] = fwd >> 8;
? message[2] = ref & 0xff;
? message[3] = ref >> 8;
+? interrupts();
}
73
toggle quoted message
Show quoted text
On 5/2/23 20:11, Rafael Diniz wrote: Correct me if I'm wrong, but better disable the interrupts just in the message writing itself. I created the PR 29. Here is the diff:
Rafael
On 5/2/23 19:36, Ashhar Farhan wrote:
Fabulous, I will roll this in. Or better?yet, can you send me a pull?
On Tue, May 2, 2023, 9:33 PM Steve Beckman <n3sb@...> wrote:
??? 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
|
Sorry Steve, I think I'm tired, this is exactly what you wrote. Anyway, the PR is correct.
: )
toggle quoted message
Show quoted text
On 5/2/23 20:30, Rafael Diniz wrote: btw, the rationale for this I just wrote - we don't want the I2C response to be delayed (IO is not the fast operation in the MCU... and we already have problems enough with bit-banging), but having a consistent read 1ms late (just exaggerating here) in the worst case is not a big issue.
I glue the diff here:
? delay(2);
? fwd = analogRead(A2);
? ref = analogRead(A3);
+? noInterrupts();
? message[0] = fwd & 0xff;
? message[1] = fwd >> 8;
? message[2] = ref & 0xff;
? message[3] = ref >> 8;
+? interrupts();
}
73
On 5/2/23 20:11, Rafael Diniz wrote:
Correct me if I'm wrong, but better disable the interrupts just in the message writing itself. I created the PR 29. Here is the diff:
Rafael
On 5/2/23 19:36, Ashhar Farhan wrote:
Fabulous, I will roll this in. Or better?yet, can you send me a pull?
On Tue, May 2, 2023, 9:33 PM Steve Beckman <n3sb@...> wrote:
??? 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
|
Hi Rafael;
No Worries. We are fortunate to have all the source code at our fingertips so that we can review, improve, change, and learn from.
I have a couple Digispark modules laying around that might serve for code testing. They have a USB boot loader which makes for easy code downloading.
Power/SWR detection kits are available on ebay cheap. They look very much like what Diz used to offer.
Since we have all the source code, it would be easy to move from the attiny85 to an AVR module with more inputs like a Nano, and use the extra analog inputs to do things like read the power supply (battery) voltage, and the PA temperature. One could easily connect a potentiometer to an ADC input and use it for direct control of CW speed, or RF power. The extra digital inputs could be used to control the sending of pre-recorded CW or voice messages.
73; Steve, N3SB
|
Hi Steve,
I wonder if the blocking of the interrupts can cause the I2C requests to be missed.
It may be better to use the flag-based approach as this will be non-blocking although the data sent on the I2C bus will be from request n-1, but this should be okay.
It may also be worthwhile adding a peak value detection so that the values are useable for SSB operation, although this may already be done in the main sbitx firmware.
73, Dave?
?
|
Peak detection should be in userland (raspberry), IMHO. But your idea is fantastic! Lets do it.
: )
toggle quoted message
Show quoted text
On 5/2/23 22:55, Dave (G8PTN) wrote:
Hi Steve,
I wonder if the blocking of the interrupts can cause the I2C requests to be missed.
It may be better to use the flag-based approach as this will be non-blocking although the data sent on the I2C bus will be from request n-1, but this should be okay.
It may also be worthwhile adding a peak value detection so that the values are useable for SSB operation, although this may already be done in the main sbitx firmware.
73, Dave
|
Couldn't we just do the read inside requestEvent()?
That would solve the problem definitely. Or use a mutex...
Rafael
toggle quoted message
Show quoted text
On 5/2/23 23:23, Rafael Diniz wrote: Peak detection should be in userland (raspberry), IMHO. But your idea is fantastic! Lets do it.
: )
On 5/2/23 22:55, Dave (G8PTN) wrote:
Hi Steve,
I wonder if the blocking of the interrupts can cause the I2C requests to be missed.
It may be better to use the flag-based approach as this will be non-blocking although the data sent on the I2C bus will be from request n-1, but this should be okay.
It may also be worthwhile adding a peak value detection so that the values are useable for SSB operation, although this may already be done in the main sbitx firmware.
73, Dave
|
Dave;
I agree with your concern. Blocking interrupts may cause an unacceptable delay in the i2c response from the attiny85. It needs to be tested.
My little digispark module is set to run at 16.5 MHz. Maybe those four variable assignments can be completed in a microsecond or so, and the i2c bus will never know anything happened.
Some instructions:
I added the link?? ?
to the additional boards manager URLs in my version 1.8.19 Arduino IDE, downloaded the attinycore? version 1.5.2 by Spence Konde using the boards manager, set the board type to attiny85 (micronucleus / digispark) hit the upload tool in the Arduino IDE, then plugged in the digispark module when the IDE prompted me to do so. The program is only using 1278 bytes or 19% of the code space (6586 bytes total available before programming) and 11% of the variable space. There's plenty of room for growth. Program sizes above are for Farhan's original code. I haven't added the interrupt blocking code or made any other changes yet.
This is going in a slightly different direction than Farhan is suggesting in his notes at the top of the .ino program. Looks like he might be using totally blank attiny85's. I'm starting with a digispark module that has a bootloader already installed.
I haven't tested it yet, just programmed it. So my "instructions" might be a total waste of time to follow. At least all the stars aligned, all the libraries needed were present, the compile completed successfully, and the code downloaded into the module!
The digispark module is set up for +5 Volts. I'll have to see if it will be happy running at +3.3 Volts. I'm not sure which option is best -- I could wire it up to +5 Volts, but then there's the remote possibility that the I/O pins might output +5 Volts on the same bus where the RTC, SI5351, and Raspberry Pi are connected, which are all 3.3 Volt devices. The other option is to connect the module to +3.3 Volts which (assuming it runs) would eliminate the possibility of 5 Volts on the i2c bus, but it does add an additional load to the 3.3 Volt regulator at the SI5351. And we know how that regulator will fail if something makes it unhappy.
73; Steve, N3SB
|
Hi Steve, With respect to the IO voltages, I believe that the sbitx peripheral devices (SI5351A, RTC) and the RPI4 are 3V3, so you should avoid driving 5V.
Generally I2C interfaces only drive logic ‘0’ and have pull-ups for the logic ‘1’, so you may be okay with a direct connection form the Digispark module.
However, to avoid any issues if you a programming whilst in circuit, you could use one of the cheap 2-channel MOSFET based level shifter modules. An example schematic of a 4-channel version is shown below.  For the few projects where I have used the ATtiny85, I use a USBASP (clone) programmer (Approx ?4.50 in the UK) and a simple homebrew board with a socket for the ATtiny.  Also, I agree it is best to avoid loading the 3V3 regulator that feeds the SI5351, since this may cause more noise to be generated on the clock outputs. Good luck with your experiments and updates. 73, Dave
|
Rafael - Not sure that we would want to have the extra code being executed after the interrupt gets called but before the message is written back out via i2c. I agree that it would eliminate the need to take steps to make the array fill atomic.
Soon we will be able to try it and see what happens.
73; Steve, N3SB
|
Right. That is what I thought... we might not want too much code inside the interrupt handler function. We could also use a flag written by any atomic ATMEL instruction and use a double buffer, if the flag is up, for eg, we use buffer 2, if the flag is down, buffer 1.
Anyway, the code you proposed disabling interrupts should be ok, as reading about the I2C, it seems that if we turn off interrupts just a bit, we'll not lose the I2C interrupt, as it will just be delayed. I need to read the ATMEGA datasheet to make sure about this (and of course, testing also).
Buuut... As the ATTiny85 might not have any other interrupt (if we remove that delay()), I also would consider reading the two ports and writing the answer inside the interrupt handler, if it all goes well... then problem solved.
: )
Rafael
toggle quoted message
Show quoted text
On 5/3/23 06:08, Steve Beckman wrote: Rafael - Not sure that we would want to have the extra code being executed after the interrupt gets called but before the message is written back out via i2c. I agree that it would eliminate the need to take steps to make the array fill atomic.
Soon we will be able to try it and see what happens.
73; Steve, N3SB
|
So, I create a better solution IMHO for the ATTiny code. As we'll only have one source of interrupt, this code should be safe, but I have no way to test before my sBitx v2 and AVR programmer arrives. Here is the PR:
73,
rafael PU2UIT
toggle quoted message
Show quoted text
On 5/3/23 10:56, Rafael Diniz wrote: Right. That is what I thought... we might not want too much code inside the interrupt handler function. We could also use a flag written by any atomic ATMEL instruction and use a double buffer, if the flag is up, for eg, we use buffer 2, if the flag is down, buffer 1.
Anyway, the code you proposed disabling interrupts should be ok, as reading about the I2C, it seems that if we turn off interrupts just a bit, we'll not lose the I2C interrupt, as it will just be delayed. I need to read the ATMEGA datasheet to make sure about this (and of course, testing also).
Buuut... As the ATTiny85 might not have any other interrupt (if we remove that delay()), I also would consider reading the two ports and writing the answer inside the interrupt handler, if it all goes well... then problem solved.
: )
Rafael
On 5/3/23 06:08, Steve Beckman wrote:
Rafael - Not sure that we would want to have the extra code being executed after the interrupt gets called but before the message is written back out via i2c. I agree that it would eliminate the need to take steps to make the array fill atomic.
Soon we will be able to try it and see what happens.
73; Steve, N3SB
|
Hi Rafael;
I have tried your idea of moving the ADC reads and message array stuffing into the requestEvent() function. The result is most unexpected.
First of all no i2c errors are being reported, so that's good.
However, the SWR value reported on the GUI is SIGNIFICANTLY different.
CAVEAT: My ADC inputs are still hanging in the breeze, with no actual Power/SWR detection circuitry currently connected.
However, by moving this code into the requestEvent() function, the reported SWR has dropped form 10.0 down to 1.0 - 1.1 - 1.2, and changeable when I tickle the ADC inputs with my finger.
I cannot explain the difference in ADC behavior. Will need to do some further debugging.
I've already run afoul of needing test flags declared as volatile in the Arduino code. Approaching everything with extreme caution and skepticism,
73; Steve, N3SN
|
Thanks Steve!
What are the values (0 - 1023) obtained from the ADC for ref and fwd?
Hi-Z readings as completely random anyway, so no conclusion can be taken.
I bought my v2 as soon as they were put to sell, but did receive yet...
:/
73,
Rafael
toggle quoted message
Show quoted text
On 5/4/23 17:03, Steve Beckman wrote: Hi Rafael;
I have tried your idea of moving the ADC reads and message array stuffing into the requestEvent() function. The result is most unexpected.
First of all no i2c errors are being reported, so that's good.
However, the SWR value reported on the GUI is SIGNIFICANTLY different.
CAVEAT: My ADC inputs are still hanging in the breeze, with no actual Power/SWR detection circuitry currently connected.
However, by moving this code into the requestEvent() function, the reported SWR has dropped form 10.0 down to 1.0 - 1.1 - 1.2, and changeable when I tickle the ADC inputs with my finger.
I cannot explain the difference in ADC behavior. Will need to do some further debugging.
I've already run afoul of needing test flags declared as volatile in the Arduino code. Approaching everything with extreme caution and skepticism,
73; Steve, N3SN
|
Rafael, Your boxes left today
On Thu, May 4, 2023, 7:43 PM Rafael Diniz < rafael@...> wrote: Thanks Steve!
What are the values (0 - 1023) obtained from the ADC for ref and fwd?
Hi-Z readings as completely random anyway, so no conclusion can be taken.
I bought my v2 as soon as they were put to sell, but did receive yet...
:/
73,
Rafael
On 5/4/23 17:03, Steve Beckman wrote:
> Hi Rafael;
>
> I have tried your idea of moving the ADC reads and message array
> stuffing into the requestEvent() function. The result is most unexpected.
>
> First of all no i2c errors are being reported, so that's good.
>
> However, the SWR value reported on the GUI is SIGNIFICANTLY different.
>
> CAVEAT: My ADC inputs are still hanging in the breeze, with no actual
> Power/SWR detection circuitry currently connected.
>
> However, by moving this code into the requestEvent() function, the
> reported SWR has dropped form 10.0 down to 1.0 - 1.1 - 1.2, and
> changeable when I tickle the ADC inputs with my finger.
>
> I cannot explain the difference in ADC behavior. Will need to do some
> further debugging.
>
> I've already run afoul of needing test flags declared as volatile in
> the Arduino code. Approaching everything with extreme caution and
> skepticism,
>
> 73; Steve, N3SN
>
|
