SoylentNews is people
SoylentNews
Congress wants to force AM into every new car for emergency alerts.
The fight over the future of AM radio got a little more heated this week as organizations representing the auto and technology industries told Congress that its plan to mandate this mode of radio wave reception is poorly conceived and will hinder progress.
AM radio has seen almost every other in-car entertainment option come and go—vinyl, 8-tracks, cassettes, CDs—and it might predate just about everything other than playing "I Spy," but time is catching up with this old broadcast technology. It is starting to get left behind as new models—many of which are electric vehicles—drive off into the sunset, streaming their audio instead of modulating its amplitude.
[...] "As more and more Americans adopt electric vehicles, we must ensure that they are equipped with AM radio. AM radio is—and will remain—an essential communications channel for emergency alerts and for disseminating news and other important information to residents of our district and communities across our country. I am proud to co-lead this bipartisan legislation which would ensure that EVs continue to be equipped with this basic but critical capability," said Rep. Bob Menendez (D-N.J.), another co-sponsor.
(Score: 2) by DannyB on Thursday May 25 2023, @05:40PM (10 children)
First of all, please forgive any poor description that follows. I am NOT an RF guy.
I've watched SDR videos on YouTube. I've used a cheap dongle to play with SDR myself.
What you will typically see (either on videos, or if you try it for yourself) is that the software display shows quite a bit of spectrum. You can see where in the spectrum signals are located. Then move your little 'red line' to that part of the spectrum and hear it, or decode it if it is a digital transmission. So the hardware doesn't "tune" to a specific frequency. All of these frequencies across a wide range are seen in software and visualized on the display. You simply pick out what part of what you are seeing that you wish to listen to.
However you can see the constantly changing signal energy in all of the adjacent bands simultaneously.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Thursday May 25 2023, @06:11PM
I haven't dug into SDRs (yet) but did a quick search. It looks like there are several topologies, ranging from mostly digital sampling / processing, to much analog tuning / amplification / filtering then digital sampling. It'd take more research to find out what is more common in typical SDRs.
In other words, you may have a "digital" UI, but using DAC (digital to analog) the system can control analog tuning circuits. You'll always get a more sensitive receiver if you can do better RF tuning and amplification, rather than wide-band amplification and then filter. Reason: amplifiers also amplify electrical noise, including their own noise. The more tuning and tuned filtering you use, the more you literally tune out (filter) the unwanted spectra. Some noise will still be present in the desired tuning frequency, but the signal-to-noise will be much better.
Antenna size and tuning are a huge factor too.
Even with all of that analog tuning / filtering you'll still get adjacent frequencies. The better the filter, usually the more "narrow" its bandpass (unless you're designing for a wide bandpass or "mesa" (tabletop) frequency response because you need a bunch of frequencies at once, such as spread-spectrum systems).
Transistors are getting better and better, less inherent noise, so we can do more amplification with less tuning circuits and let the DSP handle much of the tuning and signal "detection" (word used long ago to describe the process of extracting the useful information out of a modulated RF signal).
Being a bit pedantic, SDR could also be partially a "software controlled radio" where again, software controls some of the (legacy) analog circuitry.
(I purposely didn't get into low-level specifics like "local oscillator", frequency synthesis, PLL, varactor diodes, heterodyning, IF amplification, ..., but I can talk mov, jsr, ret, push, jnz, pop, and nop if you like. nop is my personal favorite.)
(Score: 2) by RS3 on Thursday May 25 2023, @06:16PM (8 children)
Augmentation: in pure theory, SDR is almost infinite bandwidth, and all done by sampling / DSP. But you'd need some unearthly sample rates, and even unsolarsystemly DSPs to do it. Although not quite DC to light, commonly available SDRs have very impressive tuning bandwidths. I need to do some more market research / studying...
(Score: 3, Interesting) by DannyB on Thursday May 25 2023, @08:20PM
There are some videos about how the SDR actually works.
It's been a while since I toyed with it. So my memory may be fuzzy.
Something beats or somehow lowers the frequency range to something acceptable to a DAC. But I don't think it is superhet, which I remember fondly from the 1970s in my teens.
Something is done involving phase shifting the original wave by two different phase shifts, and doing something something involving some ugodly complex math, and then getting something useful. So it is almost all done digitally. There is little analog. Certainly not a 'radio' in any conventional old fashioned sense -- that happens to be controlled by a microprocessor.
It really is a "software radio".
There are several different user interfaces that work with various SDR dongles you can buy on Amazon. Some of the software are open source.
Typically you can see a large part of the spectrum. Then pick (not "tune") some small piece. You can then select whether to demodulate and how to demodulate, and other options and whizbang like single sideband and other things I don't understand. You can then listen to the demodulated signal (AM, FM, etc) or treat it as a digital signal, and decode it according to various protocols, such as digital TV, packet radio, etc.
The lower I set my standards the more accomplishments I have.
(Score: 3, Informative) by DannyB on Thursday May 25 2023, @08:30PM (6 children)
In case it helps, here are some things I had bookmarked long ago:
https://www.youtube.com/watch?v=fOlz0OcZPjc [youtube.com]
https://www.youtube.com/watch?v=qCiyN9llVGA [youtube.com]
https://www.youtube.com/watch?v=9PwQmDcSUow [youtube.com]
https://www.youtube.com/watch?v=PN0hFGfv-4g [youtube.com]
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Friday May 26 2023, @12:31AM (3 children)
Thank you for those java tutorials that happened to use an SDR for the project. :)
Seriously, thank you. Very interesting. I see that below 30 MHz or so the CPU can do most of the processing- very little analog hardware involved. I'm not sure how sensitive it is.
I was thinking of receivers more in the GHz range, where you can't sample fast enough to do purely software radio without more analog hardware- amplifier, mixer which gives the "heterodyne" or down-shifted lower frequency that you can then sample and do DSP.
Here's an interesting project (C++): https://gist.github.com/threeme3/dc6e02a3a1c2ba49e717ac622719e720 [github.com]
(Score: 3, Informative) by DannyB on Friday May 26 2023, @02:29PM (2 children)
You must remember the wisdom of SN that Java is very slow.
Despite the runtime having what may be the most advanced JIT compiler on the planet, the product of more than two decades of intensive research after IBM opened it up as open source to researchers long ago.
Back in September 2019 they removed the maximum heap limitation of 16 Terabytes of RAM. So now the only practical limit -- that I can find anywhere -- is the Linux user space limit of 128 TB. If you use one of these two GCs in Java:
* Oracle's ZGC
* Red Hat's Shenandoah GC
Then even with these enormous heap spaces, you still get a max GC pause time of 1 ms.
Another thing about real GC, as opposed to reference counting (hereinafter referred to as "fake" GC), is that you've moved all of the memory management out of the main workload and on to other cpu cores. Thus the primary application doesn't spend any cpu cycles on memory management. You don't have these points where a single dispose triggers an avalanche of deallocation and destructors. The primary Java workload can just malloc away as if memory is infinite, and malloc is designed to be very cheap. The clean up GC crew runs on other cores. Thus Java programmers have no concern about silly things like memory or cpu cycles, or efficiency.
Here is the Java Hello World, Enterprise Edition. [github.com] A program truly worthy of being a Java program. One criticism I could offer is that it did not use XML configuration files so that some things could be reconfigured without changing the source code. Things like the actual "hello world" message, or which output class to use. After all, there could be many different possibilities for where you want the Java hello world to go.
Here is the Java FizzBuzz Enterprise Edition. [github.com]
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Friday May 26 2023, @06:35PM (1 child)
Wow thank you for all of that. It's too easy for us humans to hold onto memories of past experiences. I don't think I ever commented that java is slow, but if I was ever to make such a comment, it would be in the context of that specific experience. IE, perhaps java could be fast and efficient, but perhaps that particular java code, or the environment it's running on, is the problem.
I'm open-minded enough to know my experience is specific. Most of what little experience I've had with java stuff has been on MS Windows machines. And some years ago, not with gobs of RAM, probably single core CPUs, etc. I don't think I've run, or am not aware of running a java app for at least 8 years now...
One sore spot I remember: something I was trying to do that was java code, required a very specific runtime version. If you updated the runtime, as we're supposed to always do, the program would refuse to run. I had several situations where that happened, but one I remember specifically: a Cisco GUI for programming Cisco routers. Cisco IOS CLI is its own world, and I needed to significantly reprogram a Cisco router at the time. Well, needless to say, I didn't have enough time to learn everything about IOS programming and the many many pratfalls of entering things in the wrong order (oh, the router would route, but much more slowly than potentially possible if you knew the far too many secrets to Cisco programming). So I hoped the GUI java app would do the job.
Oh yeah- another problem was it would only run through IE, and a very specific version of IE. Hours and hours wasted just trying to get a Windows machine set up with the correct IE and java runtime, make sure to disable _all_ automagic updaters, and even then (days later) something else didn't work (I forget what...)
Purely Cisco's fault, of course. But also: you had to have a very specific java app to go with your specific router, and not all routers were supported with a GUI java app.
I ended up using a commercially available router with built-in web-based GUI and it worked swimmingly and have never looked back at Cisco IOS (sho run...)
All that is to say: why would a java runtime update break a java application? They don't honor backward compatibility / support older APIs?
(Score: 2) by DannyB on Saturday May 27 2023, @10:47PM
If you have a Java program that requires a very specific runtime version, then I would blame the developer. It seems that the developer would have to go out of their way to make a Java program depend on a specific runtime.
As for browsers, it was a bad idea to allow any third party executable extensions such as:
* Java Applets
* Flash
* Microsoft ActiveX
* Microsoft Silverlight
I have also seen web sites that were written to very specific browsers and versions.
In the early 2000s a lot of sites coded to specifically IE, and then IE 6.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Friday May 26 2023, @12:42AM (1 child)
Ah yes, that 4th one is very interesting. Notice that it covers 10MHz - 3.5GHz, but the bandwidth is only 30.72MHz. That means the RF analog circuits can handle the entire range (and likely much lower), but the sampling / DSP can only do up to 30.72MHz, so you basically tune somewhere and you have a 30.72MHz range, or "window" into that frequency span (often called a "band"). That matches up with what I was saying before, and makes sense based on what reasonably cheap hardware can do these days. Maybe someday we'll be able to sample and DSP in the GHz ranges! Not likely soon.
(Score: 2) by RS3 on Friday May 26 2023, @12:48AM
A bit more research says the "LimeSDR Mini" has Bandwidth: 61.44 MHz, which is 2x 30.72, so maybe the spec. in the YT video meant the bandwidth is ±30.72MHz. Hmmm- that may be for the LimeSDR, not "Mini"... Either way it's quite useful.