ca_michelle

@attila I saw there was a new update, and downloaded it. It appears to be handling the Broadcast messages better now...with no erroneous NAKs showing. Although I can't verify the REJ part, unless we intentionally reject a message. Thanks for your help Michelle

Thanks @attila, I look forward to trying the next update, when it's available.

Thanks @attila I've given it a go, and it appears mostly OK, for general messages. But appears to have an issue with ACKs on Broadcast messages (Dst = F), and thinks they are NAKs. I'm guessing it doesn't realise that "For broadcast messages the sense of the ACK bit in inverted to allow for a single device to reject a message". So it needs to recognise it's a broadcast message, and then decode the ACK bit accordingly. For reference, here is the start of the same transaction (run separately, as you can't capture both at the same time) using the Digital section of the Scope instrument. It correctly recognises the ACKs, even for broadcast messages. I hope this isn't too much of a pain to fix. I've not tried the TX option, so not sure if that has any issues. Regards, Michelle

Thanks @attila The Reset Starts has done the trick with issue (1). The Record mode does help a bit for (2)...I'll play around with the settings, to get the best out of it. But being able to get the data out in text form (not graphical), from the Protocol instrument, will be a real advantage, when it happens ? Regards, MIchelle

@attila Sorry for delayed response. the last week or so has been manic. I've tested the CEC decode, and the bit order is now correct, thanks. However I've noticed a couple of other issues. 1) If I trigger the scope/logic analyser using the CEC protocol, Start bit... the first packet is not decoded. but if I trigger just using simple trigger, falling edge of CEC line, it does. Of course triggering like this, it doesn't always align with the start of the packet. The I2C decode works fine, even on a single packet. 2) It doesn't appear in the Protocol Analyser instrument, only the Digital (Logic Analyser) section of the Scope, which is only really suitable for a few packets at a time, due to screen resolution and memory depth. Some transactions of CEC are up to about 20 packets at a time, so having it in the Protocol Analyser would be very useful. Is the any change of correcting number 1, and adding number 2? Thanks, Michelle

Thanks @attila...I'll download it now, and let you know if successful.

....

Hi, I've been trying the HDMI CEC decode with AD2 on waveforms (version 3.16.3), and it looks like the bit order is wrong, it should be MSB first for each nibble/byte. I found this old forum post, which requested it's creation. So in the example on that post, it should decode to Start, Src h8, Dst h1, End, Ack 0,.... There's no option to switch between LSB and MSB, only invert the polarity, which doesn't fix the issue. And no way to modify scripts for existing protocols, only create a custom one from scratch. Is there any chance this could be corrected?, as reordering the bits manually defeats the object of having a protocol decode. I did comment on the post, but as no-one else was following it, I thought it better to create a new post, and link to the old one. I'm new to the site, so not sure if that is the best way to do it. Thanks, Michelle

Hi, I know this is an old post, but I've just been trying the HDMI CEC decode with AD2 on waveforms (version 3.16.3), and it looks like the bit order is wrong, it should be MSB first for each nibble/byte. So in above example, it should decode to... Start, Src h8, Dst h1, End, Ack 0,.... There's no option to switch between LSB and MSB, only invert the polarity, which doesn't fix the issue. And no way to modify scripts for existing protocols, only create a custom one from scratch. Is there any chance this could be corrected, as reordering the bits manually defeats the object of having a protocol decode. I'm happy to create a new post, if needed, but as new to the site, I've not done one before. Thanks, Michelle