I/O Board Fault Code 157?

[Jan PA3JRK]

Hello group,

This Fault Code pops up randomly (1 - 2 times per minute) below the waterfall in Thetis

I'm using Thetis 2.10.3.4. Despite the faultcode, everything works fine, as far I can see. I also tried Thetis 2.10.3.5 beta1, which produces the same faultcode. Already tried to reset the database, but this does not resolve this thing.

It looks like a hardware thing. Any clues/hints what this can be?

Best 73,

Jan, PA3JRK

[Jan PA3JRK]

Hello group,

It looks if I "solved" this thing by reseating the IO board. After reseating the IO board I didn't see this faultcode anymore.

Best 73,

Jan, PA3JRK

Op vrijdag 15 maart 2024 om 08:02:53 UTC+1 schreef Jan PA3JRK:

[Scott Massey]

I hope you are right.  I’ve had the same issue but I’m pretty sure it’s not a connection (hardware) issue.  It seems more like it’s a I2C timing issue that is heavily influenced by processor overhead.

Hopefully, someone will enlighten us what is fault code 157.

Scott Massey | M +1.248.535.6510

(iPhone transmission)

On Mar 15, 2024, at 10:22, Jan PA3JRK <jrkui...@gmail.com> wrote:

Hello group,

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/b1030e7a-5279-472c-a060-033deec64d6fn%40googlegroups.com.

[Clifford Heath]

If it might be an I2C timing issue, it should be possible to test that using an experimental gateware that clocks I2C at a slower rate. Perhaps James can confirm that is possible.

Unfortunately I'm away and can't build that for you at present.

Clifford Heath 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/FDD3EE37-1582-4E6A-BB8C-BCADF057DFB7%40gmail.com.

[Reid Campbell]

Hi Scott, Jan,

In Thetis, an I/O Board fault is shown when register 8 in the I/O protocol is non zero. Thetis polls this register on a regulator basis and if it contain a non zero value, it will display the fault message, along with the value of the register.

I would only expect this to happen if you are running custom firmware on the I/O Board, as I haven't heard of any other indications using the default I/O Board firmware. I would make sure that the register value has been initialised correctly to zero.

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/FDD3EE37-1582-4E6A-BB8C-BCADF057DFB7%40gmail.com.

[Scott Massey]

Hi Reid,

I am taking the voltage output of a Stockton bridge and inputting it to ADC0 and ADC1 (FWD and REV power) of the Pico.  I've only uploaded Jim's suggested code to the Pico, no modifications.  

On the PC side I run the N2ADR HL2 Control Board code with two additional lines of code to convert my Stockton Bridge voltage to watts for both FWD and REV indications.  All I'm doing is multiply the ADC result by a simple conversion factor of 16.3.

  elif name == "ADC0":
          read_i2c = self.ReadBoard(25)
          if read_i2c:
            Reg[25:25 + 4] = read_i2c
          v = Reg[25] << 8 | Reg[26]
          v = v / 4095.0 * 3.0

          v = v * 16.3  <--- my addition

This conversion or scaling factor reliably indicates both FWD and REV power with the exception of a fractional indication, typically less than 0.5 watts, at zero transmit power.  Perhaps this is a question for Jim but should I add some additional filtering to my bridge output and/or an additional line of code or two that treats this low value as zero?  I ask because I'd like to "settle down" the indication and possibly fix the fault code issue.

Do you guys think this is possibly related?

Thanks, Scott KE8KYP

[Reid Campbell]

OK, so you have two separate programs talking to the HL2 at the one time, both making I2C requests. I suspect that they are tripping over one another when doing I2C register requests.

I can't think of an obvious way to sync the I2C without changes to the FPGA gateware as it is the common element.

Cheers 

Reid
Gi8TME/Mi0BOT 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/3964a036-d5c0-4415-9c41-27098698c972n%40googlegroups.com.

[Scott Massey]

Hi Reid,

It’s curious that the alarm is always in reference to the IO Board and not the HL2 process itself.  I don’t disagree with you but if it’s a collision of requests, one might think that at least occasionally a HL2 alarm might occur.  In Jim’s notes he writes that you must exercise care in developing code.  Perhaps it’s situations like this he was referring to.

Hey Jim,

Reid stated earlier that he thought the 157 alarm was a non-zero value in register 8.  I’m thinking he might be right but I’m curious what you think.  Does IO Board fault code 157 seem like an I2C issue?

Thanks guys, Scott KE8KYP 

[Reid Campbell]

Hi Scott,

On 17/03/2024 10:51, Scott Massey wrote:

Hi Reid,

It’s curious that the alarm is always in reference to the IO Board and not the HL2 process itself.

The alarm is generated by Thetis as it is polling the I/O board reading the value of register 8. When the collision occurs, the value 157 has accidentality been returned as the contents of register 8. As it is non zero, Thetis thinks the contents are a fault code return from the I/O Board and displays it as such, hence the 157 fault code. 

 I don’t disagree with you but if it’s a collision of requests, one might think that at least occasionally a HL2 alarm might occur.  In Jim’s notes he writes that you must exercise care in developing code.  Perhaps it’s situations like this he was referring to.

Hey Jim,

Reid stated earlier that he thought the 157 alarm was a non-zero value in register 8.  I’m thinking he might be right but I’m curious what you think.  Does IO Board fault code 157 seem like an I2C issue?

As above, 157 is the contents of register 8 and relates to no particular error.

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/bd33546c-fc7a-4e9d-969c-42df75877f79n%40googlegroups.com.

[Scott Massey]

Hi Reid,

I see.  When Thetis attempts to read the port and the IO Control program is using it, register 8 is 157 (non-zero) thus picking the alarm.  It would seem that the IO Control program is primarily a development tool and not intended to operate in parallel with Thetis because it is an independent process.

The real effect of this alarm in this case is benign. Two questions:

1. Can HL2 “ignore” or treat the 157 value as non-zero if the IO Board is checked?

2. Can a meter within Thetis use the FWD and REV data from the IO Board?

That second one was an earlier request but I thought I’d bring it up again since an external method to capture external SWR through the I2C port is proving troublesome.

As always, thanks for your assistance,

Scott KE8KYP

[Reid Campbell]

Hi Scott,

On 17/03/2024 12:57, Scott Massey wrote:

Hi Reid,

I see.  When Thetis attempts to read the port and the IO Control program is using it, register 8 is 157 (non-zero) thus picking the alarm.  It would seem that the IO Control program is primarily a development tool and not intended to operate in parallel with Thetis because it is an independent process.

There is no sync between the two processes, so they are always going to tramp on each other over I2C access.

The real effect of this alarm in this case is benign. Two questions:

1. Can HL2 “ignore” or treat the 157 value as non-zero if the IO Board is checked?

When you talk of the HL2, do you really mean Thetis, it's the one with the smarts. The HL2 is a RF network device and needs a SDR program to make a proper SDR transceiver. To make it ignore some value is just a kludge, so no.

2. Can a meter within Thetis use the FWD and REV data from the IO Board?

That second one was an earlier request but I thought I’d bring it up again since an external method to capture external SWR through the I2C port is proving troublesome.

It will at sometime but it's well down the list at the minute. The other option is to feed your signals directly on to the LPF board, replacing the ones from the internal detector.

Cheers 

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/957d6752-a855-4366-88e9-e101b0be5971n%40googlegroups.com.

[Scott Massey]

Hi Reid,

Yes.  I meant Thetis.  Sorry about that.

I agree that the "ignore" proposal was not a great one but thought I'd ask.

I look forward to being able to select an alternate source of FWD and REV data for a SWR cross meter in the future.  In the meantime, I'll use the IO Control Panel periodically to check the performance of my external amplifier. 

Thanks again, Scott KE8KYP   

[Reid Campbell]

I did have a quick look at the metering code and I can sort of see the structure of the way it work. The problem is I don't really understand how the meter values are pulled in and it's not a rabbit hole I have the time to go down at the minute.

It will happen but the format of the values crossing the I/O Board protocol needs to be confirmed. I did make a suggestion but so far no responses.

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/612d4bd3-1759-466e-9e28-3f7ac4b77702n%40googlegroups.com.

[Scott Massey]

Hi Reid,

Thanks for look.  Jim's code seems simple enough, on the IO side, but I can only guess how the Thetis side works.  Can you point me to the metering code?  I'd be interested in seeing it.  I doubt I can do anything but you can't learn if you don't look.

Thanks again, Scott KE8KYP

[James Ahlstrom]

Hello Group,

As Reid said, the message from Thetis for error 157 means that Thetis read register 8 and the value was 157, not the expected zero.  There is no standard meaning for an error code of 157 and the only defined meaning for register 8 is that zero means no error.

Register 8 and all other registers are initialized to zero by the system since they are global statics. So one explanation is that code running on the Pico is writing 157 to register 8. To test, you could run my code in n2adr_basic to see if the 157 occurs. It does not write to register 8.

A timing error on the I2C bus is unlikely. The Pico is an I2C slave and has no timing parameter. It relies on the I2C clock provided by the HL2. If there is a timing problem, then all registers should show the problem, not just register 8.

Note that only one I2C read can be outstanding at a time. And if you are sending I2C read requests to ports 1024 and 1025 at once, it is up to the gateware to sequence them, and I don't know if it does that.  In any case, an I2C read can return an error code of 0x3F in RADDR.  All PC software should be checking for the error code to see if the I2C read request succeeded. If the read failed, then the value of register 8 is invalid.

Jim

N2ADR

[Scott Massey]

Hi Jim,

On my machine, the 157 error pops randomly.  It can be fairly frequent, say once or twice within about 10 seconds to once every 30 seconds or more.  I've been using the N2ADR IO Control program to monitor the ADC0 and ADC1 output.  The error doesn't seem to affect the SDR functionality nor does the ADCx values seem to be disrupted.  It's just kind of curious.

I'm running the IO Control program from a command prompt and I noticed a number of retries in the command window.  I don't know if that means anything but I just noticed it.  The retries are not occurring at the same time as the 157 error but it's difficult to be sure.  There are more retries than the 157 errors.

Does this information help?

Scott KE8KYP

[Reid Campbell]

The file you should look at is MeterManager.cs in the Thetis source code. Let me know if you find anything.

Cheers

Reid
Gi8TME/Mi0BOT

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/01f1ca46-5769-46bb-b934-22a8a294994fn%40googlegroups.com.

[Scott Massey]

Hi Reid,

Wow!  That is a lot of code.  I can see why it will take a while to sort it out.

Thanks, Scott KE8KYP

[James Ahlstrom]

Hello Scott,

The "Retrying send" message comes from hermeslite.py. It means that a message sent to the HL2 did not return a response within 2 seconds. That is confusing. I thought that if you send I2C requests on port 1024 and 1025, and if they collide, then an error response would be returned for one of them. It looks like one is dropped instead. 

I see you are displaying register 8. Did you ever see 157 in it? 

Jim

N2ADR

[Scott Massey]

Hi Jim,

I see you caught that.  Nope, never saw a change.  It was my guess that the non-zero register entry came and went before it could be displayed.

Is there another test I can run for you?

Scott

Scott Massey | M +1.248.535.6510

(iPhone transmission)

On Mar 19, 2024, at 12:06, James Ahlstrom <jah...@gmail.com> wrote:

Hello Scott,

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/edce9998-b9c7-4b0f-a261-c7306bc7f547n%40googlegroups.com.

[Michael DG1CMZ]

Hi all,

I started a HL2 + Pico project recently where I use the pico to control a homebrew transistor amplifier. I made modifications to the N2ADR firmware to implement my external hardware and worked off the python script to connect to the pico and visualize the parameters derived from ADCs and I use register above 200 to exchange information between the pico and the python script. All works fine except I get the error 157 described above. Evidently it comes from I2C glitches between Thetis and the python script. The script itself and the firmware do what they should in principle. It was reported above by others that the error shows in Thetis but without consequence. At least in my test case it does have a consequence: it switches off the transmitter (MUX, TUNE) whenever the error pops up. So I have not gotten much further to test the amp and integration thoroughly as I can barely transmit longer than a few seconds before the next error trips the PTT. Neither my firmware adaptation nor the python script attempt to read or write register 8 and its always the exact same error displayed.

Has anyone found a solution to this yet? Is there a way to let Thetis at least ignore the error even if detected and displayed to not trip the transmitter?

Michael