Onno (VK6FLAB)

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

  • 147 Posts
  • 798 Comments
Joined 2 years ago
cake
Cake day: March 4th, 2024

help-circle






  • I think we’re agreeing that the notion of encryption is subject to interpretation and you are absolutely right in pointing out that the regulator gets to decide what it means unless challenged in court.

    I like the SSTV example because it’s not obvious how to decode it, requiring tools to do so. The same is true for ft8 and Olivia for example.

    I don’t exactly know where the line is and based on my experience with this, I think that it was written like that on purpose.


  • While I take your point, I’d like to observe that you’re not quoting from the actual legislation which doesn’t talk about encryption, instead it describes the notion of “obscuring the meaning of the signal”. (13.2.d.iv)

    See: https://www.legislation.gov.au/F2023L01648/asmade/text

    Before you tell me that this is describing encryption, consider Morse code, which requires you to know that a “dit-dah” means the letter “A”. This is like having a code to represent something else, just like the word “Alpha” means the letter “A” and “QTH” means your operating location.

    In other words, if there’s a common understanding of the meaning, it’s not obscured, but it can still be encrypted.

    I realise that this is a fine line, but the word encryption doesn’t require that nobody knows.






    1. No it doesn’t scare mobile phone networks.
    2. Radio amateurs who are testing this are reporting all manner of issues.
    3. The source code was forked and people got their noses out of joint.
    4. I see no evidence that this will scale anywhere near the penetration of mobile phone networks.
    5. It shares the LoRA frequency bands that are miniscule compared with the spectrum use of mobile phones.

    Edit: Removed item 3, there is a split, though apparently not strictly a fork, in the “meshcore” community, not “meshtastic”. While I’m aware of these projects, and have read numerous posts from fellow radio amateurs, I’m not following closely, mainly because I have plenty of other amateur radio projects to pursue.










  • Have a look at your AWS billing console, since data egress is charged and downloading to verify is considered egress.

    AWS S3 supports data checksums where a checksum is calculated at AWS, which you can compare against a checksum that you calculate locally.

    This is an article that goes into how it works, but I’ve not (yet) tested it, but I’ll be following in your footsteps pretty soon.

    https://medium.com/@maureenosaghae86/check-the-integrity-of-data-in-amazon-s3-with-additional-checksums-3e51fe45f530

    As an aside, make sure that versioning is OFF on your backup bucket unless you specifically require and understand it, because even when you delete objects, they persist as a previous, all but invisible, and charged(!), version.

    My former backup software “helpfully” enabled versioning and I was left with a $600 monthly bill for six months while there was no actual backup being done due to a local hardware failure, until I figured out what was happening. I used that software for years and shudder to think just how much extra it actually cost.

    I will note that while I had a catastrophic hardware failure, I didn’t lose any data.

    Finally, if you’re storing data in Glacier, retrieval is charged at different rates, depending on timelines of access, so it might be that your backup software is using the slow tier to “save” you money.

    Edit: OP advises that they’re not using AWS, instead they’re using OVH. The object storage solutions appear to be mostly compatible, but I was unable to discover if the OVH implementation supports checksums.