search

jopohl / urh

Universal Radio Hacker: Investigate Wireless Protocols Like A Boss
GNU General Public License v3.0
10.95k stars 871 forks source link

Separate in time slices like inspectrum #770

Closed Phreak87 closed 4 years ago

Phreak87 commented 4 years ago

it would be great to see a feature to define time or sample based slices on the data like a fixed raster. This would be great because i work with the Yard-Stick and have to define the PWM-Bits manually. (as Example: 1 = 110 and 0 = 100). For this it would be simpler to draw a raster and directly can see the exact Bitrate over a long Time period and can take also a better decition whats the best way to generate a nearly perfect PWM-Signal. The best example how this should look like is a software called "Inspectrum". This feature seams to be often used by the community

andynoack commented 4 years ago

Hi, you can define a custom decoding to replace 110->1/100->0 (Substitution). This may solve your problem. Additionally, encoding (the other way around) is implemented automatically if your substitution is unambiguous.

Phreak87 commented 4 years ago

Hi, thank you for your Answer. thats right and i´ve seen this feature already. but i found no working way from my signal to a PWM-based Yardstick One Signal because some timing is always wrong. (Thats why a Raster could help to get the really exact Samples per bit/PWM-Bit). one time i have the same start and endpoint - but the width is wrong - or the other case - the width is right but the bits in between are sometimes to large/small. If i look to URH and select a Bit i often get another count of Samples i choose (With Errors: 0) My Problem is that i´m on the beginning in my Radio-learning curve and really don´t like to copy-paste without understanding whats going on. The Raster-Feature could help others and me to better understand whats going on in between- and helps all inspectrum Users who searching a Windows alternative. If You like i can send you some pictures of what i mean.

andynoack commented 4 years ago

It would be great to have some pictures.

Phreak87 commented 4 years ago

Yard

andynoack commented 4 years ago

Ok, the problem is that URH is designed to work with many different signals. Therefore there is a certain flexibility to provide the best results to the user, even for weak signals That means URH allows large variances for samples/symbol to compensate signal errors, should be around +- 40/2 in your case. This is, however, a point that we cannot change because that would make lots of other signals (with such variances) useless. The same feature is also responsible that some assignments of signalparts to bits (and the other way around) are not precise in each(!) case.

Phreak87 commented 4 years ago

I understand that point - but i don´t understand why i have to give a explicit error tollerance and samplerate if its ignored (or extended/modified) in the calculation - my understanding is i have x/samples per bit with +/- ErrorRate difference for weak signals. (a higher Tolerance like 20 makes the picture i send you realisic and comprehensible.) But all this is not part of the Main question if its possible to make such things like this (Especially TimeSelection): inspectrum

andynoack commented 4 years ago

In our implementation: Error tolerance is the number of samples that can have a different signal level within the current symbol.

andynoack commented 4 years ago

In regards to time based selection, I will discuss this in our team. I don't think there is a simple solution for this but maybe I am wrong.

Phreak87 commented 4 years ago

okey - sounds also a possible interpretation to give a tolerance inside the 40 Samples. What do you think about the Screenshot? its possible to implement a sample raster´ (But without modifications of the detected Bit-Sample width) - just straight 40 - Line - 40 - Line ...

Phreak87 commented 4 years ago

Missed your last post in between writing. thats great. Thank you!

andynoack commented 4 years ago

URH's philosophy is different from inspectrum's. Changing the way (like argued above) how URH assigns bits to a signal part is not an option, because that will influence many people using URH in the current form. Adding a grid would produce a lot of GUI effort (incl. zooming and so on) and the benefit is marginal as there won't be a connection to the "digitalization engine", because that one has to stay as it is. Maybe we can help you with the de/encoding of your current problem but with techniques that are implemented in URH right now. Join our slack channel for practical support.