[semi-spam] sdr struggles continue
I am so excited that I got to work on my shielding testing ideas a little bit more! The gnuradio qt block "time raster" is really inspiring. Given a packetlength it aligns the data along that length, so it can be used for visualising unknown packet signals like clocked refresh emissions. I dunno where I'm supposed to learn that but I didn't know about this block for years and years. Of course I am using it for developing "noiscillate" which is my personal project for measuring shielding effectiveness without a high quality radio. Long ago, before schizophrenia, I could complete something like this within a few weeks, so it is very confusing to me for it be taking years and years, and I'm not sure that I'm making the right decisions around it. One high quality radio my father gave me long ago I don't know where is, the other one is a N210 I got to test the new wideband scanning research people were linking back and forth a bit ago. Unfortunately I don't have a daughterboard for my N210 yet, and it doesn't look like something I should try to figure out how to afford until next month. Still, it's cool you can purchase the radio in parts like that. It seems ridiculous to me, as a lifelong hobby algorithm researcher, to require an expensive radio with an fpga, to implement a sample algorithm, when computers have massive gpus nowadays and common math libraries to use them. I'm sad the researchers implemented their algorithm on an fpga, making it harder for people to use. But I imagine it is how they were trained, from before using gpus for math was common. Probably makes it much easier to work with massively high sample rates, which the N210 nicely provides. I'm currently rebuilding gnuradio. Somehow my "debug" build folder got reconfigured for "release" before I last installed it. I'm now getting a crash in the library whenever I run some graph containing a receiver block, and there are no symbols to debug it with. The form of noiscillate is simple and I've mentioned it before on the list, but it's very hard for me to physically reach my work and cognitively go through the motions of continuing it. I appreciate the stability offered by gnuradio blocks, where if I clean my block up enough I could share it with the gnuradio tree, giving future people something to stumble upon if I fail to continue my small work.
I have a relay connected to pin 4 of a raspberry pi, maybe like this one https://www.amazon.com/Kyoto-Electric-KF0602D-Solid-State/dp/B00B888WVC ? Relays are a very basic electric component that most electrical people would know about. They let you turn things on and off with a microchip. On the relay I have a noise generator. It just outputs noise when powered. I drive the pin with a 40hz square wave, using a gnuradio block. By setting the time raster block's column number to the period of the square wave I can visualise it. This is something I've tried to do for years and only just managed to do! The visualisation helps stabilise work when issues happen, letting you see what is going on under the hood. One next step for visualisation for me right now is to make an accumulation block that combines many signals into one: decimating them in the packet domain. But right now my system ran out of space for some reason building gnuradio. How did I build it before if cleaning and rebuilding it exhausts space?
The plan I've made for naively measuring shielding effectiveness from an oscillating noise source relies on constructing ... Huh I freed up 600mb on my system and it just ran out of space again, frustrating ...
All day I've been rebuilding gnuradio to try to make things work again. The current noiscillate plan is in the .readme file on that git repo subdir. I had some fixes and improvements I wanted to make to things but I'm still restruggling with gnuradio. Meanwhile! There are all sorts of blocks that help.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 hello Karl, this sounds like great fun :) my comments below in the clear, as usual... ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, May 22, 2021 4:53 AM, Karl <gmkarl@gmail.com> wrote: ...
It seems ridiculous to me, as a lifelong hobby algorithm researcher, to require an expensive radio with an fpga, to implement a sample algorithm, when computers have massive gpus nowadays and common math libraries to use them. I'm sad the researchers implemented their algorithm on an fpga, making it harder for people to use
the reason FPGA's are so common, particularly in TX scenarios is that time constraints for low level protocols are extremely tight. there is a non-trivial amount of latency for a round- trip to the bus, and then operating system is non-real-time. if you are receiving only, then this becomes less important so for your use case, maybe just downcoverters and RTL-SDR? keep going! you'll only make it better :) best regards, -----BEGIN PGP SIGNATURE----- iNUEAREKAH0WIQRBwSuMMH1+IZiqV4FlqEfnwrk4DAUCYKldul8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0NDFD MTJCOEMzMDdEN0UyMTk4QUE1NzgxNjVBODQ3RTdDMkI5MzgwQwAKCRBlqEfnwrk4 DLZWAP4ypTTMnA+cZnQAA7lr/yvMWnmy1KhMzeKp5oBN/L8+xAEAtVRMMXFeTe4Y qRpXg8nzvVWoCPA11W0nHQecC8V5vnQ= =lEdl -----END PGP SIGNATURE-----
It seems ridiculous to me, as a lifelong hobby algorithm researcher, to require an expensive radio with an fpga, to implement a sample algorithm, when computers have massive gpus nowadays and common math libraries to use them. I'm sad the researchers implemented their algorithm on an fpga, making it harder for people to use
the reason FPGA's are so common, particularly in TX scenarios is that time constraints for low level protocols are extremely tight. there is a non-trivial amount of latency for a round- trip to the bus, and then operating system is non-real-time.
if you are receiving only, then this becomes less important so for your use case, maybe just downcoverters and RTL-SDR?
keep going! you'll only make it better :)
makes sense. great for the military. designing for fpgas isn't very common; esoteric both to have and program. if you can change what you're doing to support higher latency, more people can help you build and improve it. but it looks like more people are learning fpgas in the next couple decades. i infer a lot of commercial protocols require low-latency. haven't learned about them. it's kind of you to translate with me a little.
the reason FPGA's are so common, particularly in TX scenarios is that time constraints for low level protocols are extremely
I thought about this a little more and I'm obviously in the wrong. People want high sample rates, and that means more data than you can send over a bus to do anything at the same rate it's being sent. it's kind of you to translate with me a little.
participants (2)
-
coderman -
Karl