Sigrok support?

[hackrid]

Hello,

What is the current status regarding sigrok support?
Thank

[imbuedhope]

This is an implementation of the SUMP protocol for Arduinos. I am not sure if PulseView supports it. That's a question for PulseView maintainers.

[ildar]

sigrok definitely supports SUMP, see https://sigrok.org/wiki/Category:Sump_protocol
sigrok observes the derivative implementation, see ddrown/stm32-sump#1 but doesn't work well.
I guess something can be tested right away.

[gillham]

I haven't tested this with sigrok. Anyone else?
I moved in 2017 and haven't had time to get my boards out of the boxes. I'll see if I can test with sigrok with some hardware, maybe this weekend.

[PeterMortensen]

Isn't RLE required, as the limitation for continuous sampling (for a reasonable sampling speed) would be the communication channel? On the Sigrok website, https://sigrok.org/wiki/Openbench_Logic_Sniffer, it says:

"RLE mode is currently broken due to samples count being passed in from Sigrok is the total samples we will receive, but however the OLS sees this as compressed samples so in turn we can never know how many samples will get send back."

I haven't tried it yet, and I am currently instead using the opportunity to use a Forth system (AmForth was chosen the Arduino) for a real project: a logic analyser that uses RLE for the transfer of information to the host system, sampling as fast as possible (the 4 MHz) and sampling at a lower rate (but still as fast as possible) during the RLE processing and producing output.

If all goes well I will have the first useful version ready today - I need to sample a 433 MHz radio system with a bit time of 150 µs and long sequences of bits (total on the order of 500 ms). In the first version, the protocol will be proprietary/adhoc. On the host side, after data collection of arbitrary length, the data will be converted directly into Sigrok .sr files by a Perl script.

[Harvie]

In theory it should work in pulseview/sigrok with mentioned https://sigrok.org/wiki/Openbench_Logic_Sniffer driver

However there are some extensions to original sump protocol in this implementation. See:

http://dangerousprototypes.com/docs/The_Logic_Sniffer%27s_extended_SUMP_protocol

Especialy interresting is the metadata part:

http://dangerousprototypes.com/docs/The_Logic_Sniffer%27s_extended_SUMP_protocol#Proposed_meta_data_format

This allows the device to introduce itself and present the sigrok software with some basic info like number of channels and maximum samplerate, so GUI does not offer impossible samplerates to user.

[Harvie]

So i've just tried and this works for me in sigrok pulseview including triggers:

However there are two annoying problems:

Firstly for some weird reason the device SENDS BUFFER IN REVERSE ORDER!!! This means signal goes from right to left. Ending at 0ms timestamp, starting at positive timestamp corresponding to buffer length. Can anyone explain what causes this to me?

Also device maximum sample rate is not properly detected. Not sure what causes this.
http://dangerousprototypes.com/docs/The_Logic_Sniffer%27s_extended_SUMP_protocol#Proposed_meta_data_format

It looks like it's reported by device. Not sure if this format is ok:

void get_metadata() {
...
  /* sample rate (4MHz) */
  Serial.write((uint8_t)0x23);
  Serial.write((uint8_t)0x00);
  Serial.write((uint8_t)0x3D);
  Serial.write((uint8_t)0x09);
  Serial.write((uint8_t)0x00);

And as was previously mentioned, the RLE support is currently broken on sigrok SUMP driver side (=no continuous capture)

[Harvie]

I've added this to sigrok wiki: https://sigrok.org/wiki/Arduino

[dralisz82]

Hi,

I've also bumped into this problem recently, and managed to fix it on the firmware side!
See my fork on GitHub: https://github.com/dralisz82/logic_analyzer

The question that which side shall be fixed, OLS firmware or Sigrok software is valid.
So I've tested my Arduino Mega based logic analyzer with 2 PC-side softwares:

1. OpenBench LogicSniffer by Jan Willem Janssen
2. Sigrok/PulseView

It turned out that sw #1 expects the data in the order the Arduino sends. See attached screenshots on both software displaying the same UART traffic: the pattern is the opposite on them. (Note: this is already the reversed order, my patched Arduino firmware sends.)

Let's suppose the OpenBench LogicSniffer by Jan works correctly. I've not checked the SUMP description, yet. So the long term solution would be to fix the problem in a next release of PulseView.

Anyway modifying the firmware to send buffer content in the opposite order was quite easy:
I've simply replaced
for (i = 0 ; i < readCount; i++) {
lines, where we are dumping in all 3 files with
for (i = readCount-1; i >= 0; i--) {
.
Reversing triggered data dump was a bit trickier, but also done. :)

So I've released my patched version for everyone's convenience. It works well with PulseView 0.4.1. Please note it will not work anymore, if PulseView side gets fixed.

BR,
Szilárd

[gillham]

I’ll look into the metadata issue. That shouldn’t be too difficult to add. The “reverse order” issue is more of a question of who is properly following the spec.

…

On Jun 29, 2019, at 11:02 PM, Tomas Mudrunka ***@***.***> wrote:  So i've just tried and this works for me in sigrok pulseview including triggers: However there are two annoying problems: Firstly for some weird reason the device SENDS BUFFER IN REVERSE ORDER!!! This means signal goes from right to left. Ending at 0ms timestamp, starting at positive timestamp corresponding to buffer length. Also device does not properly report supported sample rates as described here: http://dangerousprototypes.com/docs/The_Logic_Sniffer%27s_extended_SUMP_protocol#Proposed_meta_data_format — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[dralisz82]

Hi gillham,

Unfortunately the SUMP specification doesn't mention the order of the measurements to be transferred. Based on this "lack of information" I think your implementation is the correct one as it is the straightforward understanding.
Also the OLS Client you were referring to in README interprets it the same way.

So we can say I've implemented a "wrong" version of your code to be compatible with the (I think) wrong implementation of the ols driver in Sigrok. ;) Simply it was easier to do.
I also hope it will have a permanent solution on Sigrok side, if it turns out it is indeed the place to fix this.

BR,
Szilárd

[ildar]

did anyone notify sigrok guys about the difference?

[gillham]

I haven’t. I haven’t used Sigrok yet with any of the SUMP gear. I will try to test it eventually as I have the OpenBench Logic Sniffer also. If you can file a bug report with Sigrok that would be helpful.

…

On Nov 25, 2019, at 10:28 PM, ildar ***@***.***> wrote: did anyone notify sigrok guys about the difference? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[dralisz82]

Hi,

I've contacted them via their IRC channel.
So they are aware of it.
However it's not the most practical channel for such conversation, as I could not follow up the outcome.

It's great to hear you have the FPGA based sniffer! Please let me know what results you get with it!

Thanks!

BR,
Szilárd

[positron96]

Hi! Does anyone know the current status of sigrok support for this? My pulseview does not even detect an Arduino Nano via serial port. I tried pulseview 0.4.2 on windows and pulseview 0.4.0 on ubuntu

[khimaros]

@dralisz82 -- thank you for your work to fix the recording order. Were you able to get RLE working in PulseView? I can't seem to achieve continuous capture with my RedBoard (ATmega328 based, equivalent to the Arduino UNO R3) on PulseView 0.4.2.