On Thu, Jul 2, 2020 at 9:58 AM Gerhard Sittig <gerhard.sit...@gmx.net> wrote:
> On Wed, 2020-07-01 at 23:38 +0400, JULIO AGUIRRE wrote: > > > > Added 2 more dumps for PJON decoder test. > > > > dump1.sr > > Bus id tx rx = 0.0.0.1 sender id 44 reciver id 45 payload = > "01234567890" > > decoder does not get correct alignment on sender ID, configuration... > etc > > > > dump2.sr > > sender id 44 reciver id 45 payload = "01" > > i removed bus id but still not able to align id, config, etc. > > Well, open the file, look at the signal's timing, do the math. Do > you remember when I asked you to come up with a set of rules on > paper (forgetting that decoders might exist, or may get created)? > Rules that follow the available spec, and allow you to interpret > the data that you see in the capture. What is _your_ interpretation > of that capture, can _you_ see valid packet content there? > > My guess is that the signal does not meet the spec. The sender's > clock appears to be short by some 7% or more -- which is huge, > given that we talk about serial communication here! See the > attached screenshot. A 124us period translates to 2.8 bit times > which is none of the possible ways to continue at this point. > It's obvious that the byte cannot decode correctly, everything > else is consequence (remainder of the packet). > > When I cheat and interpret the data at the incorrect clock speed > (all other things identical, just assuming 92% clock speed), the > decoder yields more output. The two 32bit bus IDs don't look > pretty but their values are shown. The "0123456789" payload data > is seen. The checksum lost two bytes between 0xd4 and 0x49. But > zooming in reveals that the input data lacks their sync pads so > that their bytes cannot be seen. (This could be the sender's > omission, or a flaw in the acquisition.) > > The second dump also decodes (payload "01") when the wrong clock > is assumed. > PJON PJDL4.1 runs a completely software-defined implementation, in timing.h the different configurations for the supported devices are declared. The issue with the timing was the incorrect definition for the stm32f103 platform used to generate the dumps. After fine tuning the definitions for stm32f103 the decoder works almost flawlessly in the dump3.sr. Looks like the max variation in timing duration is 1uSec. As you point out in the decoder comments, maybe there is an issue in the correct detection of the padding after the last byte bit ends in high state. Trying to get more dumps with other configurations but looks like there is a mismatch in the library documentation and the current api with errors at compilation using Packet id and 16 bit packet lenght configuration.(work in progress) > > This makes me think that the decoder does work so far, haven't > seen a problem with it yet. The input data was incorrect, and the > decoder showed what it could, and could not show what wasn't > there. The implementation even nicely supported the user in the > diagnosis of the incorrect traffic. Looks good to me. Showed how > useful it is to have that PD. :) > > > 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 >
_______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
