Walkie-Textie Wireless Communicator(technoblogy.com)
technoblogy.com
Walkie-Textie Wireless Communicator
http://www.technoblogy.com/show?2AON
129 comments
> Actually I have/had a lot of these. They can only be used with triple a batteries and don't last long.
You must be mistaking this design for another one. This one was released only a few weeks ago, and specifically offers LiPo batteries:
"The PCB has space for a 2-pin JST socket that will allow you to plug in a standard LiPo battery, such as the ones supplied by Adafruit."
You must be mistaking this design for another one. This one was released only a few weeks ago, and specifically offers LiPo batteries:
"The PCB has space for a 2-pin JST socket that will allow you to plug in a standard LiPo battery, such as the ones supplied by Adafruit."
Reminds me of what the messenger on the Cybiko was trying to be. Too bad LoRa wasn't a thing back then, it would have been more useful if it had a better range.
https://en.wikipedia.org/wiki/Cybiko
https://en.wikipedia.org/wiki/Cybiko
I remember seeing these on some tech show here in the UK - and being in love with the idea - seemed so cool and 'archivable' for a young person to own. A few years later they were dirt cheap on ebay - new/boxed, but by then the itch had gone, but I wish now I'd bought one.
Whoa, I wonder if I still have my Cybiko Xtreme somewhere.
> LoRa can reach a range of up to 3 miles (4.8 km) in urban areas, and up to 10 miles (16 km) in rural areas
In mountainous area LoRa on 868MHz band reaches over 100km. Last month we had a stratospheric balloon with a Meshtastic node attached. It established direct (albeit intermittent) connection between Warsaw and Berlin.
In mountainous area LoRa on 868MHz band reaches over 100km. Last month we had a stratospheric balloon with a Meshtastic node attached. It established direct (albeit intermittent) connection between Warsaw and Berlin.
I've tested LoRa from Hill<->Hill and Flat Land<->Flat Land and 30-60km worked with plenty of SNR left.
On 868MHz with standard 5dBi omnis.
Thesis: as long you are using one of the more robust LoRa settings it always will work as long you have LoS or at least only lightly obstructed LoS.
On 868MHz with standard 5dBi omnis.
Thesis: as long you are using one of the more robust LoRa settings it always will work as long you have LoS or at least only lightly obstructed LoS.
What's the data transmission rate with the balloon, put of curiosity?
Hard limit is 3.5kbps with 148dB link budget (Medium Fast preset in Meshtastic [1]). In practice - a packet worth of hundred bytes every half a second or so.
[1] https://meshtastic.org/docs/overview/radio-settings/
[1] https://meshtastic.org/docs/overview/radio-settings/
Is that the cap of the whole system or can multiple users use it with individual caps of 3.5kbps? That's somehow both faster and slower than I expected.
If one node kept transmitting non-stop, it could push data out at 3.5kbps and no one else in that range can transmit at the same time.
However, in EU there is a legal limit of 1% duty cycle on 868MHz band and collision avoidance mechanism, meaning on average you can send a packet (up to 255 bytes) once a minute.
However, in EU there is a legal limit of 1% duty cycle on 868MHz band and collision avoidance mechanism, meaning on average you can send a packet (up to 255 bytes) once a minute.
Thanks for the info, that's really interesting!
If you want something like this with asymmetric encryption, a qwerty keyboard, mesh range extension, and a GUI, try a T-Deck running Meshtastic.
there is also the LILYGO T-LoRa Pager
https://www.cnx-software.com/2025/08/12/lilygo-t-lora-pager-...
https://www.cnx-software.com/2025/08/12/lilygo-t-lora-pager-...
Lora data rate is still maybe 100x or 1000x higher than I'd want. I'd like something just fast enough for text chat, let's say 10 bps (maybe 3 chars/sec with some data compression), and a fallback slower rate for messaging, like 1 bps or slower (2 minutes for a 50 char messsage). That would give another 20 or 30 db of coding gain for much better range. There could even be a .01bps mode. Finally, put it on HF for worldwide range ;).
This is all deployed by hams down to around 1 cps, by the way (js8call.com).
This is all deployed by hams down to around 1 cps, by the way (js8call.com).
The Lora radios also have a longer-range 325 bits/slower mode called LR-FHSS which does frequency hopping and has 10-60 dB better sensitivity. Though only the sending part is implemented in the low power chips.
I guess this would require a Ham license in most places? Apart from that i would really like a device like you describe (extremely low bps, high range).
JS9CALL on the ham bands requires a ham license but in principle you could use it on the unlicensed bands as well.
Isn't there a ban on encrypted amateur signals? Or is this running on a band that allows for it?
Yes and yes. In the US, 900-930MHz (nominally the 915MHz band) is available for use with no license required so encryption is fine (similar to your 2.4GHz or 5GHz wifi access point).
People interested in LoRa may also be interested in 802.11ah, or Wifi HaLOW
People interested in LoRa may also be interested in 802.11ah, or Wifi HaLOW
>802.11ah, or Wifi HaLOW
Thanks a lot I wasn't aware of this technology. Turns out you can already buy gateways and boards/modules, and it seems it wasn't the case last year.
Any tip on how I can power these things wirelessly ?
Thanks a lot I wasn't aware of this technology. Turns out you can already buy gateways and boards/modules, and it seems it wasn't the case last year.
Any tip on how I can power these things wirelessly ?
I have seen low power meshtastic devices serving things like BBSes on solar power, I’m not familiar enough with 802.11ah devices to know if solar would be feasible.
Amateur, yes, but this is not amateur radio. This is unlicenced.
The Meshtastic firmware actually has an 'Is Licensed' [0] checkbox if you want to operate with both the privileges and restrictions of operating under that license.
The major upside is transmit power and the downside is not being able to use encryption.
[0] https://meshtastic.org/docs/configuration/radio/user/#is-lic...
The major upside is transmit power and the downside is not being able to use encryption.
[0] https://meshtastic.org/docs/configuration/radio/user/#is-lic...
I would also note that I have never once heard of enforcement on using encryption but we -have- seen enforcement of using too much transmit power without a license.
So if you like, get a license, crank transmit power, then use encryption all you want and don't worry about it.
It will be enforced about as fast as movie torrenting.
So if you like, get a license, crank transmit power, then use encryption all you want and don't worry about it.
It will be enforced about as fast as movie torrenting.
LoRa is surely mostly for machine to machine, Internet Of Things. There are lots of web pages that take it for granted that encrypted communications are not merely allowed but expected.
See, for instance
https://lora-alliance.org/security/
See, for instance
https://lora-alliance.org/security/
Or get a rak device that has a better antenna and range than the T deck
Oooh, which one has a keyboard?
t-deck has a keyboard and is ideal for a personal handset.
A G2 Basestation or rak device is ideal for node to node communication to act as a base station for range extension.
A G2 Basestation or rak device is ideal for node to node communication to act as a base station for range extension.
yes!!!
It's a real shame phones don't have something like this built in. I mean, we literally have satellite communication in every iPhone – or, depending on how you count, every LTE phone, period!
Technically, it seems like 90% of what's required is already there anyway, but due to commercial and political pressures, we'll probably never see it happen.
Technically, it seems like 90% of what's required is already there anyway, but due to commercial and political pressures, we'll probably never see it happen.
There's a lot of cool radio-related things our smartphones could do but probably never will for regulatory/political/commercial reasons like you note.
My pet idea is to make some use of longwave! You know those time signals broadcast around 60 kHz? They cover thousands of kilometres from one transmitter. At 60 kHz the wavelength is 5 kilometres long and the RF tends to diffract around objects like mountains, buildings, etc. that get in the way. Longwave tends to penetrate underground, and through Faraday cages meant for short wavelengths.
Those time signals broadcast, in effect, 1 bit per second. The receiver is dead simple electronically and requires almost no energy to run. What if we broadcast a more modern error-corrected data stream? Every device could be supplied with a receive-only stream of a few hundred bits a second of whatever. I admit it's a solution somewhat in search of a problem. Weather updates? Emergency alerts?
My pet idea is to make some use of longwave! You know those time signals broadcast around 60 kHz? They cover thousands of kilometres from one transmitter. At 60 kHz the wavelength is 5 kilometres long and the RF tends to diffract around objects like mountains, buildings, etc. that get in the way. Longwave tends to penetrate underground, and through Faraday cages meant for short wavelengths.
Those time signals broadcast, in effect, 1 bit per second. The receiver is dead simple electronically and requires almost no energy to run. What if we broadcast a more modern error-corrected data stream? Every device could be supplied with a receive-only stream of a few hundred bits a second of whatever. I admit it's a solution somewhat in search of a problem. Weather updates? Emergency alerts?
Some countries already do this!
For example, the German LF time signal, DCF77, dedicates some of its "spare bits" to broadcast civil protection and weather forecast information, the latter of which many simple LCD "home weather station" thermometers can receive and decode.
GNSS (navigation satellite systems like GPS or Galileo) are also an obvious candidate for this, given that essentially all phones already can receive their signals.
For example, the German LF time signal, DCF77, dedicates some of its "spare bits" to broadcast civil protection and weather forecast information, the latter of which many simple LCD "home weather station" thermometers can receive and decode.
GNSS (navigation satellite systems like GPS or Galileo) are also an obvious candidate for this, given that essentially all phones already can receive their signals.
Galileo already has search and rescue (SAR) and emergency functions (EWSS)! GPS is trickier, as it's still sort of a millitary-first platform.
> My pet idea is to make some use of longwave! […] At 60 kHz the wavelength is 5 kilometres long …
Dim memory from my Ham Radio days that you’d need an antenna length of 1/4 the wavelength, which wouldn’t be very convenient for portable devices, unfortunately.
Dim memory from my Ham Radio days that you’d need an antenna length of 1/4 the wavelength, which wouldn’t be very convenient for portable devices, unfortunately.
Only for most efficient transmission. Reception just scales with antenna size, so as long as your transmitter is powerful enough in terms of effectively radiated power, you can make the receiver arbitrarily small.
Many wristwatches are capable of receiving these LF time beacons, despite usually having antennas more compact than several kilometers.
Many wristwatches are capable of receiving these LF time beacons, despite usually having antennas more compact than several kilometers.
The 1/4 wavelength is derived from the half-wave dipole. It's not necessary to have an antenna that is 1/4 wavelength. It'll probably perform better if it is closer to that size, but it isn't required.
Actually some have. At least I know that in Peru, operators were forced to offer such a thing in case of earthquake. I do now have details though, maybe was not simple as I was told.
There's an app called Rattlegram that will convert data into audio that you can then send over a walkie talkie.
I wish the hardware was included directly in the phone. It would be super useful for outdoor activities where there's no cell service and you often end up just out of yelling distance.
I wish the hardware was included directly in the phone. It would be super useful for outdoor activities where there's no cell service and you often end up just out of yelling distance.
I would settle for push-to-talk over WiFi on my phone interoperable with dedicated devices with no monthly fees.
Not that I don't agree that push-to-talk is a cool tool, but good lord was it a scourge in public environments. People shouting into their phones, then the Nextel "boop-boop" followed by a loud static-y response while you sit on the bus wishing for an asteroid.
I'll take it over people blasting reels without headphones on public transport...
I'm fully in favor of that being punishable by catapult worldwide.
I'm backwoods camping next week, and we have 25 people spread out over three sites. I was thinking it would be funny to bring some old rotary dial phones and some sort of way of hooking them up, and then just have that as the intercom between sites for when dinner is ready or whatever.
It's next week, so unlikely to happen and I'm not sure what technology I would need to make it all work. Something like Lora plus a way to make the phones work.
It's next week, so unlikely to happen and I'm not sure what technology I would need to make it all work. Something like Lora plus a way to make the phones work.
Chaining together a few WiFi routers and running a local IRC server with ergo could work well (so get everyone on the same WLAN even if no Internet). There is also Briar chat on mobile. Maybe Mumble for voice could work. I'd look for routers on Craigslist or eBay that are under $20 each and have OpenWrt support. Have had good luck with the Netgear R6220 in the past, but there could be other good options as well.
Cheap FRS walkie-talkies, can find plenty of these on ebay if don't want to buy new (will need new batteries though).
https://en.wikipedia.org/wiki/Family_Radio_Service
https://en.wikipedia.org/wiki/Family_Radio_Service
My entire community use it. We set channel and CTSS to our area code so people can remember it. I also have intercoms that use it.
Outside of the legal realm there are also ham radios that are either easy to frequency unlock or are pre-unlocked to do FRS+DMR for encryption though I would never do this outside of a dummy load.
Outside of the legal realm there are also ham radios that are either easy to frequency unlock or are pre-unlocked to do FRS+DMR for encryption though I would never do this outside of a dummy load.
Frs was everywhere for a minute, and it seems like it’s been completely forgotten. Perfect for the application, basically the intended purpose.
Less fun but you can also run OpenBTS or Yate to get your own GSM network. Probably illegal but nobody's gonna care in the woods.
Back in the day we would "find" spools of phone cable and string them between houses. If you found that much cable you could definitely wire up a few miles of woods.
Back in the day we would "find" spools of phone cable and string them between houses. If you found that much cable you could definitely wire up a few miles of woods.
Regular walkie talkies + VOX + headset re-assembled into the phone handset ? Make the phone hook a switch to cut the mic (err, like it originally did, I guess). It's not elegant but it could be a quick evening's work.
That shouldn't be too hard actually if you know some soldering!
Hook the speaker and mic up to the phone part, wire the hang up switch or rotary pulser to the musical tone button.
The ring might be a little quiet but this would be real easy to setup quick.
Hook the speaker and mic up to the phone part, wire the hang up switch or rotary pulser to the musical tone button.
The ring might be a little quiet but this would be real easy to setup quick.
They did that on the last episode of Star Trek Strange New Worlds (rotary phones).
DeviantOllam has a few videos on YouTube about some con/meetup thing he goes to that does just this. You might be able to get a few ideas from that.
A couple years ago I stayed at an AirBnB and there was an old rotary phone in the kitchen. Unfortunately, I found it was merely placed there as an antique curio and wasn't hitched up with service. I felt a little cheated honestly.
While people did get really fast at typing on those num keypads, there was a lot of RSI injuries among people who did it often. a number key bad might be the best compromise despite that, but don't lose sight of just how bad they were and take effort to avoid the issues.
I've tried and tried to use LoRA devices w/ meshtastic for various things, and can't get them to communicate reliably. Even with two devices sitting next to each other. Not even working reliably enough to be used as a toy. What am I doing wrong?
If you are using the lilygo tdeck, I’m working on Rust support here.
https://github.com/joshmarinacci/rust-tdeck-experiments
https://github.com/joshmarinacci/rust-tdeck-experiments
Very nice. I'd like to see one like this that uses frequencies that can pass through 200m of rock. Obviously the radio frequency will need to be much, much lower (https://en.wikipedia.org/wiki/Through-the-earth_communicatio...). Why, you ask? Cave rescue situations.
It's not only lower frequency, it also need robust wireless modulation that can work with very limited LoS where LoRa perform badly. LoRa is pretty much useless in your use cases.
Currently we're working on a new wireless modulation that has much higher bandwidth (similar to HaLow) but 1000x better in BER performance than LoRa in limited LoS propagation model based on simulation. If we can get 100x improvement in real world testing for the high bandwidth version I'm more than happy. Our Japanese collaborators has tested the lower bandwidth version similar to LoRa bandwidth and frequency, and it work fine inside a bunker.
If you're interested perhaps we can collaborate on testing the solution. Already proposed to IEEE as new wireless PHY modulation but to no avail yet.
Currently we're working on a new wireless modulation that has much higher bandwidth (similar to HaLow) but 1000x better in BER performance than LoRa in limited LoS propagation model based on simulation. If we can get 100x improvement in real world testing for the high bandwidth version I'm more than happy. Our Japanese collaborators has tested the lower bandwidth version similar to LoRa bandwidth and frequency, and it work fine inside a bunker.
If you're interested perhaps we can collaborate on testing the solution. Already proposed to IEEE as new wireless PHY modulation but to no avail yet.
I was trying to do something similar with esp32+lora development boards.
And I got like 3km range in my city so it was great !
But then I wanted to make it a ""usable"" thing and started getting stuck on designing a protocol that allows multiple senders at the "same time".
I thought of doing a time slice system since this whole project was inspired by a telecommunications class I had, but the issue would be that people you would need to know in advance the number of slices and your assigned one and also the devices would have to be synchronized, and I really wanted to make it dynamic, do anyone can just turn on their thing and it does a sort of handshake until everything works.
If anyone has pointers It'd be very appreciated, I found out about meshtastic.org while doing this project too.
In the end this was my first embedded experience, and my first embedded with Rust, so at least I got something "working" but I would love to make something as "usable" as this post.
And I got like 3km range in my city so it was great !
But then I wanted to make it a ""usable"" thing and started getting stuck on designing a protocol that allows multiple senders at the "same time".
I thought of doing a time slice system since this whole project was inspired by a telecommunications class I had, but the issue would be that people you would need to know in advance the number of slices and your assigned one and also the devices would have to be synchronized, and I really wanted to make it dynamic, do anyone can just turn on their thing and it does a sort of handshake until everything works.
If anyone has pointers It'd be very appreciated, I found out about meshtastic.org while doing this project too.
In the end this was my first embedded experience, and my first embedded with Rust, so at least I got something "working" but I would love to make something as "usable" as this post.
A question for folks who know things I don't: if I wanted my phones to work in an area without cell signal, for just me and my family, is it possible to build a "personal" cell tower that our phones would just connect to and work, and allow us to text each other? Or is there a whole layer of auth required for our various phones to actually be able to use a fake network?
Yes. There is a way to setup a private cell using SDR. There was a talk about that in Chaos Computer Club some years ago. I do not remember how they did with the simcards, if they were custom, or normal out of service ones. Caution: because the spectrum band is licensed, it will be automatically illegal pretty much everywhere!
Here a quick search: https://www.reddit.com/r/sdr/comments/1bn1n5f/how_to_run_ope...
Here a quick search: https://www.reddit.com/r/sdr/comments/1bn1n5f/how_to_run_ope...
Here’s a recent post I found on open source software for that. I remember a recent post about folks using base stations that were popular with the Helium network to run their own stuff, but I can’t find it at the moment.
https://news.ycombinator.com/item?id=44936241
https://news.ycombinator.com/item?id=44936241
Possible? Yes.
Legally? No. But it's totally possible.
There are micro-towers for cell phone testing you can buy and cell phones think it's a real tower. Law enforcement uses one of them to track criminals IIRC.
But it's very tightly regulated.
Legally? No. But it's totally possible.
There are micro-towers for cell phone testing you can buy and cell phones think it's a real tower. Law enforcement uses one of them to track criminals IIRC.
But it's very tightly regulated.
Isn't this what Wifi Calling is for?
https://en.wikipedia.org/wiki/Wi-Fi_calling
https://en.wikipedia.org/wiki/Wi-Fi_calling
VoWiFi requires an internet connection. It dials back to your carrier.
Nothing preventing you from configuring a local SIP server or doing IP-to-IP calls, though. I think every platorm imaginable has some kind of free SIP client.
Nothing preventing you from configuring a local SIP server or doing IP-to-IP calls, though. I think every platorm imaginable has some kind of free SIP client.
Not really. This stuff is heavily NDA and patent encumbered. You’d be better off setting up a local wifi network and using an IP based audio call system.
I'm not sure if this applies to all carriers but with many carriers if you are on wifi you can send/receive text messages and sometimes even make calls. Certainly you could use WhatsApp or similar in that case.
...with many carriers if you are on wifi you can send/receive text messages...
How would you propose that those messages get routed if there is no connection to either the internet nor a cell provider?
How would you propose that those messages get routed if there is no connection to either the internet nor a cell provider?
Not if I'm in the middle of the woods with no connection to the outside world.
For anyone looking for an off-the-shelf solution for wireless texting, I've used the BTECH GMRS-PRO. You can send messages on the device, but it's much easier to connect it to your phone via BLE and text through the app.
However, it uses GMRS bands, not LoRA, so all the FCC restrictions apply.
However, it uses GMRS bands, not LoRA, so all the FCC restrictions apply.
While I highly doubt you'd ever get in trouble, data transmissions on GMRS are severely restricted by the FCC. You obviously need the license (though it's just a fee and covers your whole family).
In any case, I'm pretty sure this device is illegal to use for short text messages. It doesn't appear to comply with several of the restrictions on digital emissions in 47 CFR 95.1787(a), namely it appears to have a removable antenna. Removable antennas are fine for regular GMRS use, but not when the device can send digital emissions.
https://www.ecfr.gov/current/title-47/part-95/subpart-E#p-95...
Also I'd be shocked if it enforced the time limits for digital transmissions in software. This leads me to believe it's not actually type-certified for use which then calls into question anything else it does. Caveat emptor.
In any case, I'm pretty sure this device is illegal to use for short text messages. It doesn't appear to comply with several of the restrictions on digital emissions in 47 CFR 95.1787(a), namely it appears to have a removable antenna. Removable antennas are fine for regular GMRS use, but not when the device can send digital emissions.
https://www.ecfr.gov/current/title-47/part-95/subpart-E#p-95...
Also I'd be shocked if it enforced the time limits for digital transmissions in software. This leads me to believe it's not actually type-certified for use which then calls into question anything else it does. Caveat emptor.
The antennas on mine don't appear to come off, at least not easily. I read somewhere that they came off on the early models but are now glued.
It does enforce time limits. If I send a message or something that uses digital communication (like gps coordinates), it won't let me send another one immediately after.
It does enforce time limits. If I send a message or something that uses digital communication (like gps coordinates), it won't let me send another one immediately after.
Wow I'm surprised - I based my message of the manual on their site which pretty clearly shows a detachable antenna and says nothing about time limits. I wonder if they received something from the FCC saying they can't market a GMRS radio that isn't type-accepted.
Why wouldn’t they comply with tx duration? You don’t want excessively long tx as you can’t rx at the same time. You’ll lose messages.
There is no amount of time that guarantees you won't interfere with another user on a shared channel without time division. Any protocol used has to account for it no matter what.
But discussion of that is irrelevant because the regulation is no more than one every 30 seconds and each one can't be longer than 1 second in duration. This necessarily limits the length of messages you can send or requires more efficient modulation and/or weaker error correction at the tradeoff of worse weak-signal performance.
But discussion of that is irrelevant because the regulation is no more than one every 30 seconds and each one can't be longer than 1 second in duration. This necessarily limits the length of messages you can send or requires more efficient modulation and/or weaker error correction at the tradeoff of worse weak-signal performance.
Can you elaborate on the restrictions? Is it just that the Baofeng allows you to transmit on some frequencies that aren’t legal or at power levels that aren’t allowed or is it not allowed in the US at all?
To use GMRS you need a license to be compliant with fcc. It’s not expensive I think $60 for 10 years and it covers your family.
You can then use GMRS. GMRS is all the same FRS channels plus several more. GMRS can also transmit at up to 50mw on some of the non-FRS channels.
To be using GMRS in compliance you have to use an FCC Part 95E certified device. These Baofeng / Btech devices are usually not GMRS certified. So you need a HAM license to use them. . . But HAM licenses doesn’t cover GMRS frequencies. So there is no technically compliant way to use these devices and check all the boxes. Even if you have both HAM and GMRS you are using a non Part 95E certified device. You’re likely fine as long as you’re not harassing people or causing interference. Generally the FCC is pretty reasonable. They send a letter saying knock it off before they knock on your door. But if you continue to harass people or use high power that causes interference then you will get a hefty fine.
At the very least get your GMRS license. But I encourage you to get your HAM license. I have found that often HAM nerds are into a lot of other stuff I like and my local club has been a welcome place to make friends and build fun stuff.
You can then use GMRS. GMRS is all the same FRS channels plus several more. GMRS can also transmit at up to 50mw on some of the non-FRS channels.
To be using GMRS in compliance you have to use an FCC Part 95E certified device. These Baofeng / Btech devices are usually not GMRS certified. So you need a HAM license to use them. . . But HAM licenses doesn’t cover GMRS frequencies. So there is no technically compliant way to use these devices and check all the boxes. Even if you have both HAM and GMRS you are using a non Part 95E certified device. You’re likely fine as long as you’re not harassing people or causing interference. Generally the FCC is pretty reasonable. They send a letter saying knock it off before they knock on your door. But if you continue to harass people or use high power that causes interference then you will get a hefty fine.
At the very least get your GMRS license. But I encourage you to get your HAM license. I have found that often HAM nerds are into a lot of other stuff I like and my local club has been a welcome place to make friends and build fun stuff.
Btech markets devices that are GMRS type accepted, it's actually one of their main businesses these days to take Chinese developed radios and modify them slightly and get them GMRS approved in the US.
I think you said "50mw" when you meant "50 watt"
You need a ham license to do most anything with a Baofeng legally.
[deleted]
Baofeng does make GRMS- and FRS-specific radios that comply with FCC regulations.
Not true, GMRS licenses are much easier to get
While true, it's important to remember that not all ham radios that can transmit on GMRS bands are legal to do so. GMRS and FRS don't have the same "anything goes" allowances that ham operators have. Radios for these bands must be purpose built for these bands. Of course no one is going to know your compliant GMRS/FRS transmissions are coming from part 97 radio. Although most quality ham radios don't allow transmission on anything but the ham bands. The increased FCC enforcement of these Chinese radios means that many now have extra filters to reduce spurious emissions outside the ham bands, meaning they shouldn't work as well on GMRS and FRS.
If you want to use GMRS, buy a GMRS radio.
If you want to use GMRS, buy a GMRS radio.
>not all ham radios that can transmit on GMRS bands are legal to do so.
Actually, no ham radios that can transmit on GMRS bands are legal (in the US).
See 47 CFR 95.1761:
https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D...
Actually, no ham radios that can transmit on GMRS bands are legal (in the US).
See 47 CFR 95.1761:
https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D...
No licence is required to listen to any frequency.
Not event remotely true in the US. Reception of cellular radiotelephone signals is prohibited by law unless you are a participant in the conversation.
*in some countries.
Are there any free-to-tinker spectrum allocations not subject to the duty cycle limitations?
It uses the slow method where you push the same key until you get the letter you want to show up? Does anybody remember T9? You push the keys for the letters you want and it figures out what you're typing from a dictionary.
Yeah I thought he was going to say it uses T9 too, but it uses an inexplicably archaic chip so there's no way you could fit a dictionary on it.
Neat! At 24mA the suggested battery will only last 10 hours.
Shouldn't it be possible to use such a LoRa device - at least in listening mode without an active display - for much longer time periods?
LoRa is actually pretty thirsty on receive.
You’d need some scheme for synchronization if you want to reduce power consumption.
You’d need some scheme for synchronization if you want to reduce power consumption.
To elaborate on this a little bit, the conventional use isn't peer-to-peer but rather sleepy IoT nodes that periodically wake up to send to a listening base station. The IoT node transmits and then waits a specified amount of time listening for a response back from the base station.
The tradeoff is:
- The end nodes can spend the vast majority of the time in deep sleep without the radios turned on.
- The base station has access to a bigger power source (usually line voltage) and doesn't care about turning its receiver off.
- You can't, however, send data to the end nodes at arbitrary points in time. You have to wait for them to send to you and you have to reply back to them before they go back to sleep.
In a peer-to-peer system like the one in the article you don't get to make this tradeoff.
The tradeoff is:
- The end nodes can spend the vast majority of the time in deep sleep without the radios turned on.
- The base station has access to a bigger power source (usually line voltage) and doesn't care about turning its receiver off.
- You can't, however, send data to the end nodes at arbitrary points in time. You have to wait for them to send to you and you have to reply back to them before they go back to sleep.
In a peer-to-peer system like the one in the article you don't get to make this tradeoff.
There's no reason you couldn't do this in a peer-to-peer system too, especially if you only have a few nodes. Imagine for 2 nodes:
1. Each node transmits a beacon once per second.
2. While they aren't connected, each node listens for sub subset of time (say 10%).
3. Eventually one node will hear the beacon from the other. They can use this to synchronize clocks (the better your clocks the better this works).
4. Thereafter they just wake up periodically at the same time and one transmits a beacon to the other to synchronize (alternating whose turn it is).
It's the same idea as sleepy edge devices used in IoT, but just both ways. Quite a lot more complicated of course, but you can totally do it.
1. Each node transmits a beacon once per second.
2. While they aren't connected, each node listens for sub subset of time (say 10%).
3. Eventually one node will hear the beacon from the other. They can use this to synchronize clocks (the better your clocks the better this works).
4. Thereafter they just wake up periodically at the same time and one transmits a beacon to the other to synchronize (alternating whose turn it is).
It's the same idea as sleepy edge devices used in IoT, but just both ways. Quite a lot more complicated of course, but you can totally do it.
Yeah I've actually built a system like this before. The nodes didn't have power supplies with strong storage capacity but did have an infinite source of limited energy harvesting (they could extract a tiny amount of power from the environment they were monitoring).
With the walkie-textie type system you're making a different tradeoff here though that would have to be measured and assessed. Now you've got a couple of knobs to twiddle with:
- What's the max acceptable latency between sending a message and receiving it? That determines your beacon interval and becomes the factor that determines your battery life (effectively your Rx duty cycle + Tx beacon energy).
- Does transmitting the beacon at your beacon interval and only having the receiver run in a limited window around that beacon result in a larger or smaller net power consumption? That's going to depend significantly on your transmit power vs. receiver power.
With the walkie-textie type system you're making a different tradeoff here though that would have to be measured and assessed. Now you've got a couple of knobs to twiddle with:
- What's the max acceptable latency between sending a message and receiving it? That determines your beacon interval and becomes the factor that determines your battery life (effectively your Rx duty cycle + Tx beacon energy).
- Does transmitting the beacon at your beacon interval and only having the receiver run in a limited window around that beacon result in a larger or smaller net power consumption? That's going to depend significantly on your transmit power vs. receiver power.
I don‘t think you‘re allowed to send once per second on LoRa if you play by the rules due to duty cycle restrictions in the license-free ISM bands.
On 868Mhz you get 36 seconds per hour or even 3.6 seconds per hour.
Depending on your power usage sending may also be very slow.
On 868Mhz you get 36 seconds per hour or even 3.6 seconds per hour.
Depending on your power usage sending may also be very slow.
Depends on the region. That duty cycle limitation sounds like EU. In USA, there are fewer restrictions on 915MHz, but heavy limits on 434 MHz under part 15. (Subsec 15.235 does not permit pre-determined intervals and 1/sec would definitely not fly!)
Then again, the primary user of 434MHz is actually amateur radio, on which you can operate beacon transmissions if you care to!!
Then again, the primary user of 434MHz is actually amateur radio, on which you can operate beacon transmissions if you care to!!
Receipt for LoRa is low power, its transmission that kills the battery
For any radio system, receiving continuously also kills battery, just not as fast as transmitting does.
Low-power requires you to turn the receiver off for extended periods of time, but what you can do there is limited by how interactive the device needs to be, and how much the power the transmitter is willing to waste on retries/longer preambles.
For proper low-power (e.g., devices with ≥ 1 year battery life on small batteries), you're likely to need sleep periods of minutes to hours, or only waking up on physical interaction.
Low-power requires you to turn the receiver off for extended periods of time, but what you can do there is limited by how interactive the device needs to be, and how much the power the transmitter is willing to waste on retries/longer preambles.
For proper low-power (e.g., devices with ≥ 1 year battery life on small batteries), you're likely to need sleep periods of minutes to hours, or only waking up on physical interaction.
Sort of. Keeping the receiver on and listening 24/7 is going to still use significantly more current than not having the receiver on and putting the microcontroller into a deep sleep mode. The approach in my sibling comment explains how IoT LoRaWAN devices are able to use ~0 current the vast majority of the time and run off, say, a CR2032 battery.
Ok great point if the device is on it will technically use more power than off, true
Receiving is just transmitting nothing to see how it's getting disturbed
Wow, that's actually very poetic way to put it. Thank you.
You’d think with short text messages you could get way better range than even a good walkie talkie. Ie Repeat every character 1000x if you need to.
It's very beautiful, but are there apps that do this? Isn't that what Briar does? I think there may have been some others.
Amazing work with an ATtiny814, only 8KB. Love it.
Amazing work with an ATtiny814, only 8KB. Love it.
The distinctive element here is the hardware. Briar allows you to sync via local wifi and bluetooth (i.e. the range is tiny) but since it's a mesh network your message will be relayed eventually.
This device though doesn't seem to support mesh connectivity because it doesn't have this short range limitation in the first place. It uses a LoRa chip with a range of a few kilometers. The bandwidth is tiny though, for reasons that are both technological and legal. In particular your are asked to respect a duty cycle of 1% (or even 0.1%, depending on the exact frequency you're using). That's 36seconds every hour. On top of that add some cities offer LoRaWAN gateways (between LoRa devices and the internet) and the limits are even more drastic like 10 messages per day, 51 bits being the maximum payload length.
LoRa was designed for async metering of IoT devices basically. This application is pushing it to its limits I guess.
I'm not an expert, I have a couple LoRa chips but never used them, however here are some back of the napkin calculations:
Assuming a spread factor of 12 (very long rage, very low bandwith) and a 1% duty cycle, you can send about 40 messages per hour if they are short like "yo what's up". 50 chars -> 20 messages/hour. 100 chars -> 10 messages/hour.
This device though doesn't seem to support mesh connectivity because it doesn't have this short range limitation in the first place. It uses a LoRa chip with a range of a few kilometers. The bandwidth is tiny though, for reasons that are both technological and legal. In particular your are asked to respect a duty cycle of 1% (or even 0.1%, depending on the exact frequency you're using). That's 36seconds every hour. On top of that add some cities offer LoRaWAN gateways (between LoRa devices and the internet) and the limits are even more drastic like 10 messages per day, 51 bits being the maximum payload length.
LoRa was designed for async metering of IoT devices basically. This application is pushing it to its limits I guess.
I'm not an expert, I have a couple LoRa chips but never used them, however here are some back of the napkin calculations:
Assuming a spread factor of 12 (very long rage, very low bandwith) and a 1% duty cycle, you can send about 40 messages per hour if they are short like "yo what's up". 50 chars -> 20 messages/hour. 100 chars -> 10 messages/hour.
Does the duty cycle mean it's only sending a receiving for those 36 seconds of every hour? The hermit in me is enthused by communicating with this restriction.
IANAL/IIUC, it can also be, e.g., 10ms every 1000ms, and it only applies to emission side of it. You don't have to actually put away the device for an hour after picking up once if the modem is not sending 36 seconds straight. But it does divide the data rate by 100.
I would have loved this as a kid. Walkie-talkie range and battery life made them useless for my adventures.
[deleted]
> ATtiny814
Why do people still use these ancient chips?
Why do people still use these ancient chips?
The ATtiny814 is hardly an ancient chip. It's a member of Microchip's TinyAVR 1-Series that was released in 2017 and still being developed, with the 2-Series being released in 2020/2021.
Perhaps you're confusing it with the older ATtiny841 (released in 2012), which was an upgrade of the original ATtiny84.
Perhaps you're confusing it with the older ATtiny841 (released in 2012), which was an upgrade of the original ATtiny84.
They're cheap, robust, readily available, super easy to develop for, have a well-chosen set of peripherals that can reduce BOM even further (e.g. the CCL)… what's not to like?
They have the same price and availability as Cortex M0 chips, are more difficult to develop for (8-bit AVR ouch), and seem to have a similar number of peripherals as any microcontroller.
The RP2350 is the same price and several orders of magnitude more capable for example.
Really though, how many of these is he making? 3? Cost isn't a factor.
The RP2350 is the same price and several orders of magnitude more capable for example.
Really though, how many of these is he making? 3? Cost isn't a factor.
> are more difficult to develop for (8-bit AVR ouch)
I think this just comes down to philosophy. ARM gives you a way richer tool-chain… and you need it. The complexity to do anything skyrockets. You have a compiler in the loop so achieving deterministic performance is much more complicated... not to mention caches. The tooling for doing statistical analysis is infinitely better; but just sitting down with a pencil and doing static analysis will always be both simpler and more accurate. For cases where you're writing thousands of lines, I too will generally prefer ARM -- but if you're just writing a couple hundred instructions, assembly is just less to think about.
Similarly philosophical is "more capable" -- an RP can handle many more use cases, I agree, but if both handle a given use case, with the same quality, then neither is more capable /for that use case/. And the one that achieves that use case at quality with the simpler implementation is, in my philosophy, preferable.
Also, while there are equivalents to the CCL in other processor families, it's by no means universal; and it's not at all rare that the CCL saves one or two external chips.
I think this just comes down to philosophy. ARM gives you a way richer tool-chain… and you need it. The complexity to do anything skyrockets. You have a compiler in the loop so achieving deterministic performance is much more complicated... not to mention caches. The tooling for doing statistical analysis is infinitely better; but just sitting down with a pencil and doing static analysis will always be both simpler and more accurate. For cases where you're writing thousands of lines, I too will generally prefer ARM -- but if you're just writing a couple hundred instructions, assembly is just less to think about.
Similarly philosophical is "more capable" -- an RP can handle many more use cases, I agree, but if both handle a given use case, with the same quality, then neither is more capable /for that use case/. And the one that achieves that use case at quality with the simpler implementation is, in my philosophy, preferable.
Also, while there are equivalents to the CCL in other processor families, it's by no means universal; and it's not at all rare that the CCL saves one or two external chips.
> several orders of magnitude more capable
I'm looking forward to seeing a LoRa texter that's several orders of magnitude more capable /i
I'm looking forward to seeing a LoRa texter that's several orders of magnitude more capable /i
If people kept buying ATMega328P to control intergalactic subspace modems, that is what gets made and sold. These things run primitive C code at practically infinite speed. That's all that matters.
[deleted]
5V devices continue popular.
Why not?
Thanks. I'll stick to a walkie-talkie. FRS radios are cheap, easily obtainable, and will work as far or farther than this 915 MHz stuff.
If you get into deep shit, some amateur FM handy-talkies are IMHO more likely to be able to get you help. Or perhaps T-Mobile's T-Satellite service if you are headed somewhere really remote.
Unpopular opinion: Meshtastic is a solution in search of a problem.
If you get into deep shit, some amateur FM handy-talkies are IMHO more likely to be able to get you help. Or perhaps T-Mobile's T-Satellite service if you are headed somewhere really remote.
Unpopular opinion: Meshtastic is a solution in search of a problem.
There is no resend or reliability in the message sending. If it fails you must retype it. I can't remember exactly if it even indicates it fails? I remember testing with two devices, one in a faraday to test bad conditions.
In the end they got salvaged for parts from my kids for other projects.
The goal was to have a simple backup/emergency communication device and get to learn about LoRa. Not sure which other devices I will try but definitely know more what to look for now.