"While it is not intended to be Chrome-only, no attempt has been made to avoid using facilities which are not yet implemented in other browsers. Safari (Mac, 7.0.4) is known to work functionally but with broken flexbox UI layout, and Firefox (29) doesn't work at all (WebSocket fails to connect). Currently, the client must have the same endianness and floating-point format as the server"
For someone's personal project I'm not sure why anyone would choose to avoid the new shiny features of their preferred browser given that those features will wind up in the others eventually. It was the same situation with HTML5 where devs jumped at the ability to write code that was forward compatible and to hell with any 'legacy' browser that wasn't modern enough.
For community OSS projects I would never expect them to spend time mucking about with cross browser compatibility given that they will be eventually consistent.
As the author, I'll say that there's a large amount of "ooh shiny bleeding edge" and "if it works for me it's fine" going on. I see that newer Safari has a _different_ failure mode and I should look into that… okay fixed https://github.com/kpreid/shinysdr/commit/67327273
Can anyone recommend a decent overview of SDR these days coming from a software (non hardcore maths/physics background) perspective? A few years ago it seemed like a fascinating area but the hardware was still quite expensive. I guess it has gotten cheaper? I am mostly interested to see what kind of signals are in the local environment, and maybe increase my understanding of some common wireless protocols.
The thing that happened is RTL-SDR, which is _not_ the name of a product but refers to the _use_ of a mass-market TV receiver USB device that happened to have a raw IQ signal mode in the hardware (RTL2832U chip). This being so cheap ($15-20) lots and lots of people jumped on it and this created a lot of interest in SDR in general.
I don't have a good overview to recommend you, but for ‘what kind of signals…’ I do recommend grabbing a RTL-SDR device, and just reading about how to use it should give you lots of pointers into the rest of the SDR world.
it would be Wrong™ in my opinion to put such things as screenshots in the repository (since doing so permanently increases the total size and it's more like a build product than a source file)
(I keep not wanting to because I see all the not-really-finished things in the UI.)
I don't get all these complaints about no demos/screenshots. It's like people don't want to spend 8 hours screwing with GNU Radio, gr-osmosdr and the obsolete version of Python required to run them, tracking down a driver for hardware that they may not actually own, setting up the hardware itself, and then making all this stuff work on a server that may or may not actually exist at the moment.
Personally, I blame today's culture of instant gratification.
A public demo instance is blocked on adding sufficient anti-DoS provisions to the server. One possibility I've considered is to make a simulation-only version packaged for Sandstorm, which would allow for a one-click trial experience — but not show any actual RF, so the internal simulator would need to be made much richer to actually show off the features.
Some people have used it with Raspberry Pis; I don't own any myself. I tried a BeagleBone Black once and found that the CPU couldn't keep up. The CPU use will vary a lot depending on what sample rate you set and what demodulator you're using. Lots of room for improvement, too.
It turns out that UI is hard! But the biggest not-crap thing from back when I wrote that (persistent waterfall) is not actually visible in a screenshot; it would need a video.
Isn't modern web technology great?