On Tue, 2020-07-07 at 01:30 +0400, JULIO AGUIRRE wrote:
>
> First of all my apologies, i don't have a good english level.
> The information displayed by your decoder is correctly interpreted all the
> way up to the payload.
> The data frame is composed by the following information:
> FRAME INIT|ID 44| HEADER 00110111 |LENGTH 0x27 | CRC8 0x45 | BUS ID 0.0.0.1
> |BUS IDtx 0.0.0.1 |IDtx 45 |PORT 8001| DATA 0to9 0to9 | CRC32 4f74f218 |
> ACK 6
>
> In the attached picture you can identify where the problem starts.
> According to my knowledge the captured frame conforms to spec.(more or less)
> [image: syncDetecFail.jpg]
>
> [ ... ]
>
> Looks like sync is not correctly identified if the previous bite is high.
> To illustrate the problem look the following dumps:
Is it valid to not have a rising edge at the start of a pad bit?
I.e. to have the last byte's MSB end in high level and immediately
follow with the high level of the next byte's sync pad? What does
the spec say about that condition? (Could not find it in either
formal format or in examples when I looked.) What does "conforms
to the spec, more or less" mean?
All sync pads of all past captures started pad the bits with an
edge. Got a problem here: How do I measure the width of something
when I don't know the start of it? Remember that I explicitly had
to weaken the spec before data would even start to decode at all.
That's when I had to deal with a remarkable error margin at the
end of a byte, which can be up to nine bit times multiplied by --
what was the tolerance of a bit time? Oh right, the spec would
not tell, but neither would real world data decode when I'd stick
with the strict spec. Stuck between a rock and a hard place. :(
Did you come up with a set of rules (on paper) how to interpret
the captured traffic? Do these rules agree with the spec, and
reliably work for all your captured data (the files which used
the correct timing)? Do the rules cover those captures where the
timing was "close enough"? Or would you agree when the decoder
rejects all input that is not exact to the fraction of a
microsecond? Where is the limit? The choice in my decoder is an
arbitrary one, as arbitrary as any other value would be. There
was nothing reasoned to it, it's a mere guess due to lack of
better information.
I can see how a human can apply hindsight, but I cannot see how a
stupid computer can resolve the ambiguity, or I'm just tired. I
won't spend more time on fiddling with and breaking the decoder
implementation, until there are clear instructions how to parse
that input data. Do try if you can find a set of rules which let
you decode the traffic. Or find out which timing is correct. When
the spec says 44us, is 44.1us wrong? Is 44.01s wrong? What's the
spec's word on this? What are the errors that are expected, and
need to get handled? How do they interact with these bytes that
"run into each other"? May look trivial, may seem like nit
picking, but it's not (not to me). Consider that in mode 1, which
uses the "widest" bit times, the smallest valid information is
just 11us wide. Add "a few microseconds" of tolerance there, and
nothing works any longer. Other modes are even harder (6.5us for
mode 4's smallest valid piece of information).
As an alternative see if you can get the decoder to work for the
recent captures, where bytes with a set MSB reveal an incomplete
implementation. Can you add support for that edge case and keep
the other features? There are lots of comments, the logic should
be straight forward to follow. Up to you to either start from the
existing decoder (which could be incomplete) or to start from a
clean state (the spec, which is _the_ reference) to come up with
a set of working rules.
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
