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 https://github.com/ddrown/stm32-sump/issues/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 notifications@github.com 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 notifications@github.com 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.

[dralisz82]

@positron96: I suggest to try 0.4.1 on Ubuntu. I've used that version. Maybe the support was introduced in that release. @khimaros: No, I've not dealt with RLE, so I have no experience with it.

[khimaros]

@dralisz82 -- thanks for the reply. Independent of RLE, did you manage to get continuous capture working? Mine seems to stop capture after ~1k samples.

[gillham]

@dralisz82 (or anyone else) do you know the current status of Sigrok SUMP support? Particularly around the data being reversed. If they fixed that, do you have a commit or other reference etc?

I need to do some testing with PulseView and I downloaded the latest nightly and stable. I need to get my signal generator out again and test my AGLA and Open Bench Logic Sniffer.

[dralisz82]

@gillham: No, I'm not following this topic these days, sorry. Since a while it drifted out of my scope.

[YazeedAlfaqeeh]

@dralisz82 , @Harvie (or anyone else) This may not be the same problem, since it's not an Arduino I'm using. but same metadata and SUMP protocol, I'm trying to implement this protocol on a Nexys 4 DDR board (Artix-7 FPGA), I downloaded the code from sump.org. I altered some parts (mainly the memory). and I wrote the whole thing in verilog instead of VHDL. now I'm trying to use a client from lxtreme to use with the board, I guess sigrok works the same way.

since the 0x04 get_metadata command wasn't originally in the SUMP protocol, I didn't implement it and it is of course required to connect the board to the client (it gives me a -Detection Failed- error). what changes do I have to make to add this part of the code ?

Do I have to write a new config file (.cfg) just for my board ? or just write a verilog or VHDL code to connect to any of the available boards/options (SUMP or OpenBench Logic Sniffer ,...) and how to any of these ? Thanks

[tmk]

Just like to share this small patch for libsigrok. With this fix Pluseview can show AGLA data in correct order.

https://github.com/tmk/libsigrok/commit/c66ea83d7e212608515fa9da5408a520bb338370

with the fix

and without it

[FernandoGarcia]

Hi @tmk !

Could you make available an executable for Windows of your patched version?

I'm trying build from source but I have lots of errors with MXE.

Thanks in advance.

[tmk]

I didn't try to building for WIndows. sigrok-util/cross-compile/linux worked well for me on ubuntu, instead.

[FernandoGarcia]

Ok, thanks!

[FernandoGarcia]

Hi! I gave up to compile the Pulseview from source. Instead I did some changes in Arduino code to make it compatible. If someone want try and help me to improve can get the code here. Also I did a PR proposing this changes. Best regards.

[joskfg]

Hi!

I uploaded the sketch to arduino Mega 2560, but it doesn't show on sigrok, it says que ID was not received. In some way once It showed up and I was able to use it, but I wasn't be able to connect it again.

I'm using this configuration in the Makefile

TARGET  = logic_analyzer
FQBN    = arduino:avr:mega:cpu=atmega2560
SERIAL  = /dev/ttyACM*

And this is the debug outout from sigrok

sr: [00:00.005707] hwdriver: sr_config_list(): key 2147418112 (NULL) sdi (nil) cg NULL -> [uint32 20000, 20001]
sr: [00:00.005733] openbench-logic-sniffer: Probing /dev/ttyACM6.
sr: [00:00.006726] serial: Opening serial port '/dev/ttyACM6' (flags 1).
sr: [00:00.006949] serial: Parsing parameters from "115200/8n1".
sr: [00:00.009233] serial: Got params: rate 115200, frame 8/0/1, flow 0, rts -1, dtr -1.
sr: [00:00.009239] serial: Setting serial parameters on port /dev/ttyACM6.
sr: [00:00.009368] serial: DBG: serial_set_params() rate 115200, 8n1
sr: [00:00.009373] serial: Flushing serial port /dev/ttyACM6.
sr: [00:00.009380] openbench-logic-sniffer: Sending cmd 0x00.
sr: [00:00.009397] serial: Wrote 1/1 bytes.
sr: [00:00.009402] serial: Draining serial port /dev/ttyACM6.
sr: [00:00.009423] openbench-logic-sniffer: Sending cmd 0x00.
sr: [00:00.009439] serial: Wrote 1/1 bytes.
sr: [00:00.009443] serial: Draining serial port /dev/ttyACM6.
sr: [00:00.009461] openbench-logic-sniffer: Sending cmd 0x00.
sr: [00:00.009470] serial: Wrote 1/1 bytes.
sr: [00:00.009473] serial: Draining serial port /dev/ttyACM6.
sr: [00:00.009501] openbench-logic-sniffer: Sending cmd 0x00.
sr: [00:00.009510] serial: Wrote 1/1 bytes.
sr: [00:00.009513] serial: Draining serial port /dev/ttyACM6.
sr: [00:00.009541] openbench-logic-sniffer: Sending cmd 0x00.
sr: [00:00.009550] serial: Wrote 1/1 bytes.
sr: [00:00.009553] serial: Draining serial port /dev/ttyACM6.
sr: [00:00.009581] openbench-logic-sniffer: Sending cmd 0x02.
sr: [00:00.009591] serial: Wrote 1/1 bytes.
sr: [00:00.009595] serial: Draining serial port /dev/ttyACM6.
sr: [00:00.029685] openbench-logic-sniffer: Didn't get any ID reply.
sr: [00:00.029693] hwdriver: Scan found 0 devices (ols).
No devices found.

Command executed:

./sigrok-cli-NIGHTLY-x86_64.AppImage -l 5 --driver=ols:conn=/dev/ttyACM6 --samples=200

WDYT?

[gillham]

Ok, I made some updates to support Sigrok. Please test the 'logic_analyzer_sigrok' sketch and let me know.

Sampling a square wave.

./sigrok-cli-NIGHTLY-x86_64.AppImage --driver=ols:conn=/dev/ttyUSB0 --config samplerate=4Mhz --config pattern=External --samples 128 --channels 2
libsigrok 0.6.0-git-585cda0
Acquisition with 1/6 channels at 4 MHz
2:00000111 10000111 10000111 10000111 10000111 10000111 10000111 10000111
2:10000111 10000111 10000111 10000111 10000111 10000111 10000111 10000111

Sampling a 100KHz "directional" bit pattern (b00011101) at 1MHz:

../sigrok-cli-NIGHTLY-x86_64.AppImage --driver=ols:conn=/dev/ttyUSB0 --config samplerate=1Mhz --config pattern=External --samples 128 --channels 2
libsigrok 0.6.0-git-585cda0
Acquisition with 1/6 channels at 1 MHz
2:00000000 00001111 11111000 11110000 00000111 11111110 00111000 00000000
2:00111111 11110001 11000000 00001111 11111000 11110000 00000111 11111110

[Iangitpers]

I know this is old, but I'm having Sig rok issues, but not with jawis OLS from xlextreme.

For clarification: when we did the open bench logic sniffer the original open source FPGA design used reversed byte order for samples, probably because it was an old low resources FPGA and down counting was easier than resetting and up counting. I know this because when we first got everything going with the OG sump Java client it was reversed.

Jawi updated the original project with profiles and you can set if byte order is reversed in the device profile files. We used this for other LAs in the Bus Pirate, logic shrimp, logic pirate, and IR toy where it was easier to return from 0 to n instead of n to 0. This is also when we drafted the extended sump protocol.

Has anyone tried Sig rok sump lately? It's been a few days of frustration, and I'm pretty sure it's broken, at least under windows. Even forcing the right number of samples immediately after 0x01 run command only works 50% of the time. I can see the USB CDC buffer has two runs worth of data, but Sig rok fails silently on the first.