Donald Ziems

Understood on the delay, and agreed that the lack of a single standard is unfortunate.

Hi Afonso,

The scope came back somewhat early, I've updated its firmware, and I see no change in behavior using FW 2.6.38 (release date 2023-11-02).

Just as in the file attached before, if there is a delay between bytes sent after the reset pulse, it is declared a framing error and decoding halts until the next reset pulse. As noted before, that is not an invalid 1-Wire transaction; things like an EEPROM read require a pause between bytes, but do not require a reset pulse in-between commands.

I can, though it will take me a couple weeks; our scope is about to be sent out for calibration. I can run the test when it returns.
Notably, 1Wire is not mentioned in the release notes between the version I ran, 2.4.4.1152, and the latest, 2.6.38.

Hi Tek support,
Wanted to follow up and see if this is something Tek plans to address, or if there are any workarounds/settings I can tinker with to get it working?

It looks like I cannot add an attachment to my prior post, so here is the session file with the waveform re-captured at a lower sample rate. It shows the same behavior as described above.

Here is the annotated output from the EV Kit software, showing what Maxim believes it is sending and receiving during the transaction. Note the "<STD> RP" at the start, that is the only Reset-Presence cycle performed in the entire transaction (at STanDard speed):


//Read Memory, Page 4
*************************************************************************************
//1-Wire
// Reset- OD Match ROM 
<STD> RP
 69 4C 6E 27 96 00 00 00 53 
//1-Wire Packet
69 04 FF FF  AA 
//Wait for computation
<Delay 50ms> 

[AA] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [C7] [C7] 
//Command Result
<SUCCESS>
//Page Data: 
// 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
// 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

Hi Afonso,

I have a waveform file I can share, though it exceeds the upload size for this forum even when compressed (approx 70 MB). Do you have an alternative means for me to provide the file? I recaptured the waveform at a reduced sample rate and saved it as a session file, see my post below as I don't think I can add an attachment to this post anymore.

In the waveform, you will see a reset at the start, then a long string of operations and waits that ultimately results in a successful read from an EEPROM page (32 bytes containing all zeroes). Because none of the operations require a reset in between them, the decoder only detects the reset and presence pulse, identifies one framing error, and then decodes nothing after the framing error.

In the waveform capture, I am using an Analog Devices (formerly Maxim) eval kit and software to perform the EEPROM read for a product that has been released ~7 years now; while eval kits may certainly have non-optimal behavior, I would expect Maxim knows how to communicate using their own protocol and any bugs with this software should be minimal or represent corner cases at this stage in the product lifecycle.

Hello Tek support,
I'm attempting to diagnose a 1-Wire bus, and I'm finding that the MSO4x's 1-Wire decoder is flagging framing errors or end-of-packet events if there is any delay (greater than ~100 µs) between one byte and the next. A bit's time slot has no maximum time, as long as it is at least 85 µs (or 16 µs with overdrive), so there is no requirement that bytes within a packet sent via 1-Wire be sent immediately after each other, as the decoder seems to be mandating.

This is especially problematic for 1-Wire operations that require a delay between sending the command and reading the result; the decoder is never able to return the result part because it times out during the delay and idles until it sees the next reset.

Is there a way to suppress "framing errors" so the decoder will continue decoding across delays within a packet?
I'm using an MSO46 running firmware Version 2.4.4.1152.