Sigrok based RDM sniffer #1718
Sigrok based RDM sniffer #1718
Conversation
… edges and not fully working with my device
|
@kripton I noticed a sigrok related thing in your repos, I don't know if you fancy giving this a little test with whichever logic analyser you have? You might find it really useful for https://github.com/OpenLightingProject/rp2040-dongle/ too! |
|
Sure, I will give this a try the coming days. I have multiple Since I already saw that yesterday:
|
Cool, the logic sniffer should just work (it needs to be on pin 1 currently). In theory the scope should be possible although I haven't tried analogue signals yet, as I can't generate them unless the dummy device does. Happy to have a go at it though and it should be fairly simple too. If you try connecting the scope up can you share some -l 4 and --sigrok-log-level 5 captures of the setup.
I'd never even considered that. Yeah it should be possible and in theory each pin would be an input port with some minimal code changes. Obviously DMX only as it couldn't reply. Perhaps I'll try and mock it up as a client first as I'm not sure what the delay might be like from a signal arriving on the pin to getting into OLA, depending on the blocks of samples being transferred. Do you think people want multi-universe DMX only capture? I guess for a recording setup maybe.
I am, I think I submitted some DMX and RDM samples in the past to try and help get it extended. The main challenge with RDM is it's a lot more complicated. To get something high level you could just decode the command type and list the PID name, but depending on what exactly you're trying to do, you probably want to know the contents of the different PIDs, particularly the discovery stuff which is where things often go wrong, but possibly some other basic initial traffic, at which point you need to implement large chunks of: Plus our protobuf stuff to support that. At which point you've reimplemented large chunks of OLA. I guess we could just include OLA's library but I'm not sure if they're really interested in that sort of approach. Finally from my brief playing with PulseView/sigrok this time around, I wasn't really sure how suitable it actually was for that purpose. When you're doing discovery of a few fixtures you're quickly into tens of messages which just seemed to result in a lot of scrolling from my brief experience. Compared to something like Wireshark which seems better suited to that type of messaging. All I've done in comparison in this PR is connected a different source of samples into the existing DMXSignalProcessor code, I've written very little new or novel code here. I do mean to get in touch with the sigrok team about it, perhaps they'll be able to signpost to this or maybe they'll want to write a full decoder themselves. |
|
Okay, first results. I tried the scope in pulseview first. I was able to see my DMX frames but I was unable to do continuously capturing. And reading from the scope's memory (over LAN, didn't yet try USB) was about 64kByte/s. Don't know why but I stopped there. Then I hooked up my FX2LAFW device. With pulseview no problems, continuous capture at 1MHz, 1 channel and DMX data was clearly visible. The internal decoder did lots of mis-interpretations but attached fixtures took the signal all well. Finally, I tried the Results: I then changed the sample rate to 1MHz but results were similar: The DMX line is directly (= TTL level, no RS-485 bus drivers and receivers involved) hooked up |
|
And something about the cli parameters seems wrong. The FX2LA-device is shown in With the scope (driver So the correct "sigrok device string" including driver and device would be When only naming the driver "rigol-ds", without specifying a device, the driver is poked for a device but doesn't find one. |
|
Okay, the thing with the scope in pulseview is a bug in the current sigfox release. Fixed in git but no release since then: |
I had issues with continuous capturing with a FX2LAFW in older releases. I assume your scope channels are listed as analogue, in which case they won't work until I write more code.
It probably doesn't bode too well if the built in decoder didn't like it. Was it just bit length issues?
Ah, I think I know what's happening, my naive implementation is ignore the channel and capture width so effectively is alternating between D0 and D9 values. I think you could prove this by either adding some printing to This would tie up with it changing nearly every tick regardless of the frequency.
Yeah that makes sense, and should work I think.
GitHub does seem to have got a little flaky recently. |
The code for that bit was inspired by the collectd plugin: I might try and offer both options, as the existing means you can juse use fx2lafw and not worry about which port it's connected to, but as you say you can't pass more options or potentially control which LA if you've got two.
Yeah I hadn't even considered those sort of settings. |
True, the DMX decoder only works on binary data. Pulseview can convert the analog channel to a digital one, that's not the issue. I've built libsigrok from git master by now and the capture is much more stable now. The DMX decoder is still flaky: The two STOP bits of the START CODE are detected properly. The, the START bit of channel 1 follows but the decoder interprets it as "INTERFRAME". Thus, every byte shifts the decoder by one bit.... Trying to attach a picture: (Failed again ...)
Nope, actually same as above. The built-in DMX decoder behaves the same, no matter if the data is captured via scope of FX2 device.
Ah, you're saying that your LA has 8 channels, mine has 16 and your code is hard-coded for 8 channels? Bridging PB0 (D0) to PD0 (D8) or PD1 (D9) doesn't change much, still lots of errors and no useful data. However, the output is different: DB0 bridged to PD0: DB0 bridged to PD1:
Yep, also experienced other issues the last two week :( |
|
Regarding the incorrect decoding of obviously valid DMX in pulseview: As with my scope: "Fixed in git, no release since then": |
So what about this: When only a driver is specified (as with I had to use the |
No, but it will be an issue with this code, which rejects any non-logic packets.
That's good to hear.
I wonder if that's our bug too?
Yeah, it tries to process the first bit of every byte of sampled logic data, there's a flag present which I'm currently ignoring which would deal with that.
That does look more promising. It might be worth trying at 4Mhz (which is all we've really tested at). Did you wait a while for data to run through, and what channel data are you using (all full, all off, or real random data)? Come to think of it, I think my tests are still only sending 20 channels which probably isn't great either, but I think should work. In your case worst case it may have to process an entire frame before it finds the break and locks on. If you run it with |
I'll have a look at their code and see how guaranteed that is, or just offer two flags.
Oops, yeah I should remove that test code! I didn't get it to decode but I didn't try for too long (I think it has a restricted pattern of data). |
I realised by paralleling workaround was unlikely to work properly @kripton as the frequency of the signal would be halved because it would get two samples where it should only be getting one. Anyway I know honour the unit width field. If it doesn't just burst into life with the logic analyser, can you share up to the first couple of transition/break to short with at least I've not done anything on proper driver config strings yet, or the analogue reading of your scope (which given they are linked won't have much impact as far as I'm aware so I might push that into a future PR. |
Are you sure that this is in your code? I can also see that demo device when I run |
Oh, great. You're right, the frequency would be halved. However, with 1MHz sample rate configured, I'd expect to sample with 500kHz, which should be okay to sample DMX data.
Don't worry so much about the scope. The configuration is already so difficult in pulseview and/or the data rate for the analog values is too low. It helps a lot to see the actual signal in pulseview but I would be really surprised if it can be managed to get this working reliably and easy from the command line. |
Yes, well sort of, my code no longer defaults to demo and instead complains if you've omitted the
Yes, but the code doesn't actually do timing in the traditional sense (i.e. end-start), it just counts samples, so if you give it a 1MHz sample rate, it works out each sample will last 1 microsecond. If you consider something lasting for four sampling periods on an eight channel LA, i.e. 4 microseconds, because you've paralleled them, it counts it twice and gets a duration of 8 microseconds. Whether this is acceptable or not I'd need to check the docs and would depend on your source DMX refresh rate too I'd imagine.
Excellent thanks!
Cool, in theory it shouldn't care at all, as long as it (currently has logic outputs) and a sufficient sample rate, it should just work regardless.
Ah that's interesting, I assumed it would sample okay, but I guess the data rate has to be much higher to get the analogue level of detail. Perhaps I will park that for now. I guess I'd be curious if you can get the scope to decode DMX in PulseView in which case it might be worthwhile investigating in future. |
Yes, I can confirm that and I agree that it makes sense.
Re-tested, working :)
Yes. The big advantage of the FX2-based boards is that they can do continuous sampling. Most other devices I have here, including the HydraBus and the "original" OpenLogicSniffer allocate some memory and can hold a limited amount of samples. Depending on channel count and sample rate, this ranges from a few µs to several ms. I didn't try the HydraBus in PulseView since the number of samples at the sample rate we need is way too low. I did try the original OpenLogicSniffer and it displays the correct bits in PulseView. However the number of samples at 500kHz is limited to about 2 DMX frames. For it to work with the
Yes, I managed to decode DMX512 with pulseview. But not in realtime. Capture (triggered on the TXEN line), tranfser to pulseview, decode. Interesting to see rise and fall times but not actually interesting to capture any live DMX or RDM data with it. |
man/sigrok_rdm_sniffer.1
Outdated
| Set the logging level 0 .. 4. | ||
| .IP "-r, --full-rdm" | ||
| Unpack RDM parameter data. | ||
| .IP "-t, --timestamp" |
There was a problem hiding this comment.
Is that implemented? Doesn't seem to work with just -d -t. Maybe it's just for RDM frames?
There was a problem hiding this comment.
No, I found out some time back it wasn't implemented on the original Logic but left is present just in case it broke people's CLIs:
https://github.com/peternewman/ola/blob/sigrok/tools/logic/logic-rdm-sniffer.cpp#L86-L87
Obviously that appeared when I duplicated this code. I've commented it out for now entirely in the sigrok based sniffer. When it all gets pulled out to some common code I'll try and finally implement it too, then they'll both get it!
🥳 🎉 I've also still not tested recent code with a full size frame, so glad to see that works too!
Yeah no worries, I accidentally tested it when I started the sniffer before my olad generator and it did a universe discovery. It should all just work though given it's just different start codes and that worked fine in the original Logic sniffer. I think the only outstanding thing here would be to analyse and decode the DUB response.
Ah I didn't realise the FX2 ones were somewhat unique in that regard. Yeah not being able to do continuous would be a real pain with all my past experience of using these.
Personally I think that would just be hugely frustrating debugging RDM stuff, even if you got a couple more frames of RDM out, due to smaller packet sizes.
Okay, perhaps I'll park that for now then. |
|
Hey Peter, great to see code updates in this PR! I'd love to test them right away but unfortunately, we are relocating and most stuff (including the logic analyzers) is already packed. Just wanted to inform you that I'm monitoring this here but can't give solid feedback right now :) |
I'm impressed to see you're watching it at the commit level!
Damn, you were potentially on my list at some point to ping, although realistically since you last tried it I've only been doing some refactoring so shouldn't have broken anything! 🤞 I suspect I might get the main bits done then merge this PR, then possibly park the enhancements for the future. I was also toying with implementing some other decoders for some of the other standardised ASCs, probably mostly just for the fun of it, I'm not sure how much they exist in the wild. I assume that's also why there's not been much activity on the RP2040 is it? |
|
Well, I subscribed to this PR, so I got an email ;) |
2 participants
This supports a far wider range of devices than just Saleae devices.
Future extensions: