Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple different carrier frequencies for sensor networks #899

Open
hllhll opened this issue Aug 4, 2021 · 7 comments
Open

Multiple different carrier frequencies for sensor networks #899

hllhll opened this issue Aug 4, 2021 · 7 comments
Labels

Comments

@hllhll
Copy link

hllhll commented Aug 4, 2021

Is your feature request related to a problem?

I Am trying to analyze a wireless signal from a network of sensors, or, should I say "things".
they are using, probably some kind of cheap hardware. The carrier frequency is a little bit off for each of the transmission from the different devices. Thus If I tune demod parameters to a specific burst, it does not match others.

Describe the solution you'd like

URH Already detects the burst automatically, it would be really awesome if it could lock on center frequency of each burst by specifying the number of preamble symbols.

Describe alternatives you've considered

Currently, the only solution for me is to take it off to GNuradio and do some block magic, then Importing the symbols back

Additional context
  • The signal is a 4FSK signal
  • with a relatively narrow bandwidth, so "center spacing" param (I.E. the distance between symbols?) does not allow enough slack for the bit slicer to accept it, the carrier freq is too far off that it decodes invalid bits.

image

@andynoack
Copy link
Collaborator

To be honest, I do not think that we can integrate this solution in URH/master. We probably already have the necessary logic blocks in our code but such auto-magic behaviour would break many legacy projects where this behavior is explicitly not wanted. Additionally different center+space settings for different sections (within one signal!) will probably create an UI nightmare...

@hllhll
Copy link
Author

hllhll commented Aug 5, 2021

So what about an option to enable, disable? (disable by default)
UI Can be totally(maybe?) ignored; You already collect a "burst level" information in the form of RSSI; What about attaching the signal mean/lock freq to it?

BTW, I Have this function implemented in GRC, How would one recommend to pipe/plug the graph into URH, While keeping timestamps, RSSI and other metadata useful in GRC?

@andynoack
Copy link
Collaborator

Maybe using your custom GRC-flowgraph instead of our default GRC flowgraph (nearly empty) when using the GR backend is a solution for your problem. You could just replace it. What do you think?

@hllhll
Copy link
Author

hllhll commented Aug 15, 2021

I would like to preserve original rssi, so total demodulation and remodulation might be possible. Im using both grc and urh on windows, any reference on how to use grc as backend? (linux is fine too)

@andynoack
Copy link
Collaborator

andynoack commented Aug 15, 2021 via email

@hllhll
Copy link
Author

hllhll commented Aug 15, 2021

image
image

I Should open a bug for that? o_O

@andynoack
Copy link
Collaborator

andynoack commented Aug 15, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants