4 ms·

If you want to have a little fun then writing a python script to convert a file to beeps and recover it from beeps is quite doable. It also teaches you just ho

by kongin 5y ago

If you want to have a little fun then writing a python script to convert a file to beeps and recover it from beeps is quite doable. It also teaches you just how insane the speeds we have today are.

mekkkkkk 5y ago
Yeah, I was experimenting with a similar thing a while back. The idea was to use camera equipped devices looking at each other to negotiate data transfer through dense QR-codes. Even with that substantially larger data frame support, transfer speed was abysmal at best.
- kongin 5y ago
  Using QR codes sets you up for disappointment. I wanted to store a gpg key offline by engraving it in metal. A reasonably sized one would taken six of the largest 177x177 plates to record. The best solution I came up with was to use metallic punched tape of some description.
  - mekkkkkk 5y ago
    A v40 QR code can hold ~3000 chars/bytes. Isn't that enough for a GPG key?
    - kongin 5y ago
      It's been over two years since I looked at it, but from memory I wanted a 8 KiB key pair that I could engrave. One was to be the public key that would be scannable, the other was the private key that would be kept in a safety deposit box. The practical limit was 3KiB for the qr code and there was some metadata in the key I didn't want to lose. I can't remember if it was the private or public key that was giving me the most trouble. But the idea of just having something to point your phone at on a wall and read a signed message from me wasn't practical.
  - dtonon 5y ago
    On low error correction level you can save 2953 bytes in binary and 4296 in alphanumeric mode. The latter should be fine for a gpg key. I'm experimenting for fun on this side: https://github.com/dtonon/papiro https://github.com/dtonon/papiro
    - dtonon 5y ago
      My fault: alphanumeric mode is not suitable for a GPG key, because it is: > 0–9, A–Z (upper-case only), space, $, %, *, +, -, ., /, : and so we miss the lowercase [a-z]. Therefore we need to use the 2953 bytes binary option.
- dtonon 5y ago
  Maybe this could interest: https://divan.dev/posts/animatedqr/ https://divan.dev/posts/animatedqr/
  - mekkkkkk 5y ago
    Wow! One of those moments when you realize that someone is doing exactly what you have been doing. My hobby project was seriously called QRTX. And each data frame started with ###-- where # are padded frame numbers. Pretty much identical to this guys project. Thanks for that find, I'm chuckling. Points of difference: I was using a leading metadata frame with filename and total number of frames etc, and the receiving device were ACK'ing frame decodes with its own QR codes. Still, wow.
    - dtonon 5y ago
      You are welcome, great project :)
wdfx 5y ago
Compare also the FT8 weak signal radio protocol. Remarkably robust but serves a max of 77 bits per 15 seconds (and also hard codes radio specific codes/IDs in the message, it's not even general purpose)

by kongin 5y ago

If you want to have a little fun then writing a python script to convert a file to beeps and recover it from beeps is quite doable. It also teaches you just how insane the speeds we have today are.

mekkkkkk 5y ago

Yeah, I was experimenting with a similar thing a while back. The idea was to use camera equipped devices looking at each other to negotiate data transfer through dense QR-codes. Even with that substantially larger data frame support, transfer speed was abysmal at best.

kongin 5y ago
Using QR codes sets you up for disappointment. I wanted to store a gpg key offline by engraving it in metal. A reasonably sized one would taken six of the largest 177x177 plates to record. The best solution I came up with was to use metallic punched tape of some description.
- mekkkkkk 5y ago
  A v40 QR code can hold ~3000 chars/bytes. Isn't that enough for a GPG key?
  - kongin 5y ago
    It's been over two years since I looked at it, but from memory I wanted a 8 KiB key pair that I could engrave. One was to be the public key that would be scannable, the other was the private key that would be kept in a safety deposit box. The practical limit was 3KiB for the qr code and there was some metadata in the key I didn't want to lose. I can't remember if it was the private or public key that was giving me the most trouble. But the idea of just having something to point your phone at on a wall and read a signed message from me wasn't practical.
- dtonon 5y ago
  On low error correction level you can save 2953 bytes in binary and 4296 in alphanumeric mode. The latter should be fine for a gpg key. I'm experimenting for fun on this side: https://github.com/dtonon/papiro https://github.com/dtonon/papiro
  - dtonon 5y ago
    My fault: alphanumeric mode is not suitable for a GPG key, because it is: > 0–9, A–Z (upper-case only), space, $, %, *, +, -, ., /, : and so we miss the lowercase [a-z]. Therefore we need to use the 2953 bytes binary option.
dtonon 5y ago
Maybe this could interest: https://divan.dev/posts/animatedqr/ https://divan.dev/posts/animatedqr/
- mekkkkkk 5y ago
  Wow! One of those moments when you realize that someone is doing exactly what you have been doing. My hobby project was seriously called QRTX. And each data frame started with ###-- where # are padded frame numbers. Pretty much identical to this guys project. Thanks for that find, I'm chuckling. Points of difference: I was using a leading metadata frame with filename and total number of frames etc, and the receiving device were ACK'ing frame decodes with its own QR codes. Still, wow.
  - dtonon 5y ago
    You are welcome, great project :)

wdfx 5y ago

Compare also the FT8 weak signal radio protocol. Remarkably robust but serves a max of 77 bits per 15 seconds (and also hard codes radio specific codes/IDs in the message, it's not even general purpose)