Onno (VK6FLAB)

1 Followers
0 Following
2 Posts

Anything and everything Amateur Radio and beyond. Heavily into Open Source and SDR, working on a multi band monitor and transmitter.

#geek #nerd #hamradio VK6FLAB #podcaster #australia #ITProfessional #voiceover #opentowork

I have, just not SMA, crimped or otherwise.

Indeed I am, and thank you for your kind words!

As for coax, RG316 seems to be popular, but I have only ever used pre-made patch leads. I use SMA throughout my shack and essentially adapt all other connectors to SMA.

For the purpose of transmitting or receiving?
You do understand that California is not the centre of the universe, that states within the United States of America don’t agree on how to conduct voting, let alone agree on laws and finally, that there are 8.3 billion people on this planet, 96% of whom don’t live in, or are subject to laws made in the USA.

I’m sorry, but no.

Age validation is surveillance under the guise of “protecting the children”, which it spectacularly fails at for more reasons than I can count.

  • Everyone has to validate their age, which creates a whole infrastructure that require documents that “prove” your age.
  • A verified “under age” user will be added to a database by unscrupulous players, creating a honeypot for predators.
  • Age verification isn’t universal, isn’t uniform and regardless of the jurisdiction in which it’s implemented, won’t actually prevent content from being procured from sources outside that jurisdiction.
  • One source of objectionable content is another’s entertainment, legally so, given that laws are made in isolation from each other across borders.
  • The result of such legislation is the effective censorship of content that some lawmaker finds objectionable, which will cause more harm than good.
  • Operating System level age verification on open source platforms will spectacularly fail since they’re published outside the jurisdiction.
  • So … no.

    [FoAR] Foundations of Amateur Radio - Bald Yak 17: Adventures in Radio Data Systems #podcast

    https://lemmy.radio/post/12439351

    [FoAR] Foundations of Amateur Radio - Bald Yak 17: Adventures in Radio Data Systems #podcast - Lemmy.Radio

    While spending some quality time discovering what I don’t know about GNU Radio, I explored the notion of attempting to at least understand a little more about how an FM signal works. Depending on your background, the letters FM mean different things. In amateur radio it’s a way to encode information, generally audio, using something called frequency modulation. Outside the hobby, the letters point at commercial broadcast radio. While the two are related, they’re not the same thing. In amateur radio use, FM is a single channel of mono-audio, however, in commercial broadcast radio, there’s a whole lot more going on, interesting because it gives you ready-made access to a composite signal that’s just complicated enough to be challenging without being so complex that you need to spend hours on understanding the thing. In essence, a commercial FM broadcast signal is multiple channels encoded in a specific and documented way. This is helpful, since you can compare the documentation against ready made examples and replicate the process for yourself. In case you’re new here, I’m in the process of building a radio system, in software, using GNU Radio in a project called Bald Yak. Specifically, the Bald Yak project aims to create a modular, bidirectional and distributed signal processing and control system that leverages GNU Radio. It’s called Bald Yak because by the time I’m done, the Yak is likely well and truly shaved. One of the easy things to forget when you’re using GNU Radio Companion, is that the blocks you’re connecting together on the screen into a flowgraph actually represent software, generated when you either build or run the flowgraph. This code is currently generated in either Python or C++, making me wonder, what does the code look like, and more specifically, what code would be needed to decode FM? It turns out that an old friend, the PySDR.org [http://PySDR.org] website has a whole chapter dedicated to this process. Chapter 18, the End-to-End Example, details how you can decode one of the channels embedded within a commercial FM broadcast, the RDS or Radio Data System signal. If you’re not familiar, the PySDR.org [http://PySDR.org] website represents a whole book about software defined radio and python. It goes into as much or as little detail as you want, to explain how this whole software malarkey works, and takes you by the hand down the path of discovery. So, armed with a working example, I followed along the bouncing ball and made a working RDS decoder and I think, understood most of it. There’s a few interesting wrinkles that I’ve contacted the author, Dr. Marc Lichtman, about and we’ll see what comes of that. Here’s the kicker. The author, who is also a senior member of the GNU Radio team, started with a GNU Radio flowgraph and reverse engineered what was happening to get to the point of the code that’s available in PySDR.org [http://PySDR.org] Chapter 18. This is significant because it creates a relationship between the code I have in front of me and the code generated by GNU Radio, which means that when I start with a new flowgraph, not only do I know the steps required, I also know that the outcome is predetermined, as-in, I already know that there’s a solution. Having professionally written software for over 40 years, I can tell you that this is not often the case. I realise that I can search the Internet for an RDS decoder flowgraph, but that’s unlikely to get me to a better understanding of what GNU Radio is doing. Once I’ve clarified with the author, I’ll add the code to my GitHub project, “Fifty Things you can do with a Software Defined Radio”, specifically, “Receive road traffic information”, since among other things, that’s carried by RDS. As an aside, Rohde and Schwarz have a lovely YouTube video on the topic, “Understanding the Radio Data System”, which is giving me a whole set of ideas about things we might attempt with amateur radio repeaters, but that’s a story for another time. Meanwhile, have you considered what other signals exist on the RF spectrum that you might want to decode and how you’d go about this? I’m Onno VK6FLAB

    The links in this post contain a boatload of metadata, which means that the “IT guy” needs more training or is trolling for referral clicks.

    Edit: The links have now been updated by the OP

    I understand your point and agree that this is the thin end of the wedge.

    What we’re doing here is discussing the phenomenon and I’m highlighting some concerns.

    I believe that this is how you get a dialogue happening which will effect change, which is what we’re both advocating.

    I think that age verification is about surveillance rather than protecting children and I think it should be fought at every level.

    This is me contributing to that fight.

    In my opinion, storing a date is pretty much irrelevant unless there’s a process that validates the supplied date, otherwise every Linux user was born on 1/1/1, if not, an administrator can “fix” that

    Furthermore, that systemd thinks that it’s the place to store such information is in my opinion beyond absurd.

    Who appointed that project the source of age truth in the Linux ecosystem? What discussion was there, who was consulted and where was the vote?

    1/1/1