Hahaha. Down boy.

Thank you. I hope so

I am not at this time running my own relay, rather using standard ones. You could easily run a custom one though. I built a custom packet system based on KISS AX25 packet specs. It handles the connections, disconnects, packet splitting, CRC checks on each packet split, retries, lost packet request, automatic detection of a bad packet and a bit more. I know nothing about wifi protocols however.

I currently have 3 speed modes, 300 baud, 600 baud, 1200 buad. 1200 is basically not possibly in anything but NVIS type HF conditions.

Interesting idea! Yes, JS8CALL has multiple modes. slow, slower, very slow and the worst. lol. Its a fantastic protocol. Very robust and can be used in terrible HF conditions. Currently it is all AX25 spec packets. 200kb chunks that get split then combined back together.

JS8 is amazing, and does have an undocumented API, but its bad. Its just not right for this project. However, future plans include:

Full KISS MODEM FL DIGI - Be able to use most if not all FL DIGI modes for very fast OR robust data transsfer, and eventually protocol switching

Reticulum Network KISS packet support. To be able to then use it on hf, fm, lora, and even just plain old encrypted internet node connections. Or better yet, a mix of all the above.

ie: Use LORA RN device to send from an offgrid channel a few miles away to an HF connected base station, which then sends it to the server.

I used speficifacally KISS packets because of the future operability with FLDIGI and Reticulum.

FM on VHF/UHF is currently working OK at 1200 baud, but currently that is the limit. In the future will add support for 2300 or even 9600 bps depending on band conditions. The biggest thing is the client and server currently have to stay on the same baud and frequencies/modes.

I plan on having a winlink style switching later on that will rotate through different HF bands possibly so you can try different bands conditions.

Thank you! Many months so far. Maybe a year. Lots of breaks though. Mainly the custom 'protocol' and packet system was the worst. I am not a developer by trade. I do believe it is now quite robust though and can handle bad radio conditions OK.

Thanks!

Yes, on my desktop. Lol.

It's on a private GitHub repo currently. Once all the initial features are finished(hoping this week!), and most of the critical bugs are done, I will switch it to public.

It's a python backend on client and server. Server is currently terminal only(just logging). Server is designed to be run headless. Put in your settings and run it 24/7.

The client/frontend side is flask based and the frontend is Svelte and I chose to use flowbite as the UI/component library.

The front and backend is pretty basic. The networking, crc, packets, radio system is much more complicated. But with some guidance, most decent python and even JavaScript devs should be able to read through it and I hope help in any way they can on new features, improvements, and most importantly, bugs and optimizations.

And yes, it will be 100% FOSS. I have no business plan or anything like that for it.

Thank you!

yeah, it was the community choice:

note1pns66m3vn2t6yg23s0vphvtn63sazkw3tua34gxzwdxm6vxe9jkqzca26a

Yes, you would need a ham license to legally operate it. Not hard though, honestly.

Phase 2 will be adding reticulum network support both for ham bands, and Lora devices. You don't need a license for they as you know. But the range, while amazing is nothing like HF ham bands. I was chatting deep into Russia last night from AZ..... Can't do that on anything but HF.

Thanks, Derek!

You keep plugging osty, but there's nothing there? The documentation website is basically empty

A lil late, haha

Nice, thank you!

Thanks!

Thanks! More to come.

Thanks! Make sure to follow and keep updated. Release will hopefully be soon.

Glad to hear it! I created it from scratch, HOWEVER, it is leveraging existing software packet radio modems, TNC software. There are many out there for packet radio. You connect to it via a direct TCP connection, and send the data. The receiving side does the rest.

I created the systems for connecting, handshaking, the back and forth, splitting of packets based on size, CRC data checksums, and more. Leveraging a few python libraries for sure.

I could have saved a HUGE amount of time if I was able to utilize a packet modem software in python that did what I wanted. Unfortunately I couldn't find a good one.