tldr: Not a terrible radio, but not particularly great either. With a little app work it could be exceptional, but the manufacturer doesn’t want to spend the time or effort. Android has better functionality than iOS – but I’m an iOS user.
Background:
I have been looking for a half decent APRS Radio for my ute for a little while now. In my previous life I had a Kenwood TM-D710A with an external GPS and I really loved that radio. Unfortunately in the new vehicle my mounting options without things looking ugly are a little limited. The Yaesu FTM-300 and 400 series look like the only commercially available “brand name” units on the market and they won’t really fit nicely in the dash. They also don’t support digipeating without a TNC attached, which is something I’m looking for, to use when doing SOTA, POTA, WWFF, etc activations.
After a bunch of searching I came across the Vero Telecom VR-N7500 which on the surface looks like a really cool radio. It’s a Chinese radio built to a budget however, so it’s not without its risk. These types of products have a habit of being vapourware or abandonware, or both.
It’s a pretty unique unit. It’s a “headless” bluetooth app controlled dual band, dual receive radio, produced by Vero Telecom in China. This would be perfect me as I have an Android headunit in my vehicle, and worst case I can pair it with my phone (iPhone) to control it, all without taking up any additional realestate on my dash.
This radio was released in 2019 so it’s got a bit of a following now, and it claims to be a fully fledged APRS radio. I watched a few reviews online that flagged that the Android App is more featured than the iOS app, but that the developers were improving the iOS app. None of the reviews really went into any decent depth on the radio though, and most certainly not on iOS, so that’s why I’m writing this review now.
Vero’s website says that the iOS features are “available soon” I’m an iOS user but I do have an Android carplay headunit in my vehicle – so if the iOS app doesn’t cut the mustard I can just use that right? (Ha!) There was some information online that suggested messaging was a concern, specifically the lack of an ack message going back to the sending station.
I sent an email to the manufacturer before purchasing the radio and they assured me that yes, messaging worked, from iOS and Android (Spoiler alert: It doesn’t, not on iOS anyway).
That said, there really was no, full, in depth, comprehensive review of this radio. Which is exactly why I’m writing this blog post.
I ordered one from AliExpress and waited. It’s not really an expensive radio so I took a gamble on it.
https://www.aliexpress.com/item/1005004127598852.html
First Impressions:
The unit arrived and it was well packaged. I set the radio up and paired it with my phone, not a problem, I managed to get my local repeaters programmed fairly easily and an APRS channel programmed fairly easily, enabled “Double Ch” and I was receiving data on APRS and talking to my local repeater at the same time.
On the surface, one thing this radio does really well, is be a good, dual band, dual receive radio. As far as just using it as a VHF/UHF dual band unit in the car, and not dealing with a control head – this it does – awesomely and is priced well below what I would expect of a similar brand name unit with a control head – but that’s not what I bought this radio for. I bought it for it’s APRS functionality.
Trying to get APRS working:
I found the “Automatically Share Location” setting under the general menu under the spoked wheel in the top right hand corner of the channel selection. This is a bit ambiguous as it suggests it’s going to cause it to do something, but it actually tells the radio where (channel) to beacon its position on RF. This can be set to either the active channel or one of the 16 memories. I had a memory programmed for APRS to Channel 16, so I set it to that (It would be cool if the channel names showed up here but they don’t).
Ok, now how to get this thing to transmit on APRS? I checked the “APRS” settings menu and configured my callsign, SSID, and APRS-IS passcode but couldn’t really find anything to enable transmitting on RF. There is a “Share Location” menu which is a bit ambiguous again, there’s a toogle here for “Share location over Internet”, it would be good if there was a second “Share location over RF” in here as well (more about that later). There are “Time To Live” and a “Maximum Forwarding Times” settings – which don’t seem to affect anything – at least – I haven’t figured out what the effect. I had “Share Location” interval set to “30 seconds” but it still wasn’t transmitting over RF. Strange.
Something rather odd was happening at this point however. Whenever the radio would receive an APRS packet, it would digipeat that packet ….
ON THE ACTIVE RF CHANNEL! NOT THE POSITIONING CHANNEL AS CONFIGURED!
Despite the “Time To Live” and “Maximum Forwarding Times” setting under the “Routing” being set to zero.
Hrm, ok, what’s going on here. I shut the radio off and did some more digging.
As it turns out, there’s another, not so obvious “User Settings” menu, under the profile picture” when you open the app. Tap on your profile picture and a new menu pops up. Why the RF positioning settings are hidden in this menu is a mystery to me. I would probably have never found it if not for searching through the Facebook groups.
In this “User Settings” menu is a “Share Location” section which is actually the menu that deals with the transmitting of the radios location onto RF. In order to get this radio to transmit APRS position packets on RF you need to set an interval on “Radio Sharing”, various fixed interval options are available, unfortunately, no SmartBeaconing. The problem is that when you enable only this setting, it sends out the packets in some other digital format. To get the radio to transmit AX.25 APRS compliant packets you need to enable the “Use APRS Format” setting.
I feel like these menu options should be implicit based on another menu item under the APRS settings, and a simple “Share Location over RF” under the “Share Location over Internet” that then took the “Time To Live” and interval settings from the APRS menu would be far more intuitive.
Once this is enabled BAM! The radio now transmits APRS packets.
Now, how do we stop this thing digipeating. And what about that path? It’s transmitting WIDE2-2? That’s really odd. I want WIDE2-1, WIDE1-1 like every other APRS radio out there as the most common path? (Spoiler Alert: It can’t do that).
At the bottom of this menu there are two “BBS Routing” settings. One is “Time To Live” and the other is “Maximum Forwarding Times”. These settings appear to be duplicated in the APRS menu, and in the APRS menu appear to do nothing. The “Time To Live” setting is actually the path setting. If you go into it, it has options from “0” to “8”. This sets the APRS path for your position packets from nothing (when set to zero) to WIDE1-1, WIDE2-2, WIDE3-3, etc up to WIDE8-8. There’s no way to set alternative paths or combine paths, so running a “custom” path like WIDE2-1,WIDE1-1, or ARISS path, like every other APRS radio out there, isn’t possible.
So how about that digipeating? Well. Turns out that the digipeating option is actually the “Maximum Forwading Times” and this setting controls what path will be appended to any digipeated packets. Set it to zero and it turns digipeating off. Set it to 1-8 and it behaves exactly the same as the APRS pathing for your positioning packets. I’ve turned it off. Oh, and did I mention it digipeats onto the active RF channel, not the “Share Location” channel.
If you want this radio to digipeat in the background while you have a local repeater set as the active channel, you cannot do that.
As a side note, the “ID Signalling” section settings need to be turned off if you don’t want a data burst in your voice transmissions at the start/end of each QSO. I think these are designed to provide positioning information to other Vero radios that are talking to each other, but for every other use case it just drops digital noise at the end of each transmission. Annoying for other users who don’t have one of these radios.
As it stands the “ARPS” Settings appear to be used to set the callsign, ssid and APRS Passcode but the rest of the settings are all related to the radio/apps communication with the APRS-IS, and the “Share Location” and “BBS Routing” settings are the RF/On air settings under the “User Settings” menu. Seems odd to split them like that.
What about messaging?
So, now we’ve got positioning packets transmitting onto APRS. Let’s send a message, or … not.
Android users have reported that they’re able to send, and receive APRS messages via the Android app, with one caveat, that the radio does not send ack messages, so stations sending messages execting ack messages will keep retrying the message until the message times out, resulting in the user receiving the message multiple times. I can deal with this as my use case is actually to message my APRS Spotting service APSPOT while out on SOTA/POTA/WWFF activations. If it doesn’t get an ack it will just ignore it, so no duplicate messages coming back to me.
Android users have reported that to send a message, you just need to either tap on a user on the map and select message, at which point the app will take you to the messaging tab with a “CALLSIGN:” pre-filled in the message field and then you can type in your message to send a message. On iOS this doesn’t work. There is no option to send a message when you tap on someones callsign, and if you do manually type in “CALLSIGN:” the radio does send *something* out onto RF, but it’s not AX25, and while some software can decode it (such as Dire Wolf on my local IGate here at home), it’s not a valid APRS formatted packet.
See attached dire wolf captures that show what the VR-N7500 sends, versus what my Yaesu FT2D handheld sends.
Messaging, like digipeating, also goes out on the current active channel, not the positioning channel, so if they do fix the bug with the iOS app, then you need to switch to your APRS channel before sending a message or, you guessed it, it’ll end up on your local repeater and annoy everyone listening.
Bad decode from the VR-N7500:
Good decode from my Yaesu FT-2D:
The only conclusion that I can come to is that the “Messaging” on the iOS app is designed for inter-radio messaging, and not for APRS messaging. The feedback from Android users is that messaging does work via Android, but that the radio does not “ack” messages bound for it – while is annoying – isn’t really a show stopper. Unfortunately in iOS, you can’t send APRS messages.
No matter how I tried I couldn’t get the radio to receive a message. The “Messages” section of the app appears to show a stream of the data received over APRS, so they do show up here, but there’s no alert or notification or anything to indicate that the app has received a message bound for your callsign (and/or) SSID.
If you’re an iOS user and messaging is important to you, this radio is not for you.
Noise issues:
After I installed the radio in my car I had an issue with it’s ability mute even mild levels of interference by raising the squelch. My headunit in my car does generate some interference on the output of one of my local repeaters. This has never been an issue with my handheld, or for that matter any other radio I have had fitted to the vehicle. My FT2D can mute the noise at a squelch level of “4” (out of 15), but the Vero VR-N7500 cannot mute it unless I set the channel bandwidth to 12.5KHz and absolutely max out the squelch on the radio.
I have fitted ferrites to the power cables of the headunit, the power cables of the radio, which have helped, but not eliminated the noise. It’s only detectable with my FT2D if I hold the antenna against the screen of my headunit, and yet, it’s loud enough to upset the VR-N7500.
Running the repeater on 12.5KHz instead of 25KHz won’t be a major issue, it’ll just mean my audio into the repeater is of a poorer quality than I would like as it will have reduced deviation and potentially be quieter. The squelch just doesn’t appear to have the same range as other radios, so it is susceptible to opening squelch when you don’t want it to.
The sensitivity of the radio however, seems to be pretty good.
Other observations:
APRS traces are not plotted on the “Map” section, like many other APRS mapping services
APRS “objects” show up as the callsign of the user thats placing the object, not the name of the object it’s self
APRS “objects” don’t show up with their object information on the map, so if you rely on RF object beacons to see what repeaters are in the local area or what the weather is doing. Too bad. This also means Weather alerts/warnings won’t show up either.
When switching channels via the mic, instead of reading out the channel label, it reads out the channel number, so you either have to commit them to memory or keep the app open.
There is no S-Meter in the iOS app (I understand there is one in the Android app)
I couldn’t get the radio to pair with the headunit in my car because it doesn’t support BLE. I’m hoping I’ve got a fix for this in the works, but as this is the only Android device I own, it’s iOS only for me.
Summary:
In Summary, this could be an absolutely game changing radio, but, at least if you’re an iOS user it’s not. I really wish a review like this was available for this radio before I bought it, but, let my experience be a lesson for others.
It is a really cool, great little dual band UHF/VHF radio that does save some realestate in the vehicle, with some very cool features, but as an APRS radio – it falls short.
To quote Maxwell Smart “Missed it by that much”
If only the app was better this radio could make the manufacturer an absolute killing. It really is riddled with glaring UI/UX issues that are immediately obvious to anybody who’s ever worked in app design and/or software product user development. It could literally have redefined everything we’ve come to know and love about mobile radios in the HAM Radio community. Alas, because of a poor quality app, it’s missed the mark.
I’d even be willing to pay twice the price of the radio if the app delivered all the standard APRS functionality we’ve all come to know and love. It’s like the manufacturer released a proof-of-concept radio, and then just decided not to throw any more effort at the software development – at least on iOS – and threw away everything that the software development industry knows and UI and UX. I understand a few of these bugs also exist on Android, albeit with extra functionality like CW and SSTV – but honestly I’d take a properly functioning iOS app, over an Android app with those features.
What’s next for this radio (for me?)
Where to next? Well, I’m trying to see if I can get a BLE dongle that works with my vehicles headunit. The headunit runs Android 9 so it’s getting on a bit in age now, but there are some very specific USB dongles out there that support BLE that are reported to work with Android 9, so I’ve ordered one and we’ll see what happens when it arrives.
If I can get my Android headunit talking to the radio then I can at least send and receive messages, which will allow it to do what I need it to do in the field, messaging is a core feature that I require. The lack of SmartBeaconing is annoying, but with a 30s transmit internal – where I live – it won’t increase the traffic on the network by too much and still give reasonably accurate map plots for me.
Who knows? My experience with Android may be sufficient that I’m not as disappointed in the radio, and while this review is filled with frustrations and confusion – it’s not a terrible radio – it does have some really neat features – just not the features I want to be using.
Sending it back isn’t really an option – I bought it off AliExpress and if anybody has ever tried to return an item on there, you’ll know the chances of getting your money back when returning an item are somewhere between buckley’s and none.
Bluetooth API
It appears that this device is a BLE compliant device. That means that the app communication with the radio is via a BLE API. If the manufacturer can’t/won’t/doesn’t want to improve the application, it’s certainly possible that we could write our own.
This is no small undertaking – but it’s not impossible. If we can get access to the BLE API, we could develop our own, killer, Yaesu killing (and I say that as a Yaesu fanboy) app to make this radio really shine. If the manufacturer won’t release a copy of the API, we can reverse engineer it via decompiling the Android APK – maybe – but it’s no small undertaking.
My bug/feature list (That could make it a game-changer if implemented).
- No SmartBeaconing – Again something almost every other modern ARPS radio supports
- Hidden “User Settings” menu under the profile pic with the “Share Location” option which affects transmitting of position data onto RF. Not obvious at all.
- APRS Beaconing settings are split between “BBS” in the “User Settings” under the profile picture (not under the settings wheel for the radio?) and the “ARPS” section – What’s the difference? Why are they different? Why isn’t there a “Share location over RF” in the APRS settings menu that implicitly configures the location sharing options in the “User Settings” menu.
- Two sets of “Time To Live” and “Maximum Forwarding Time” settings in the BBS settings under the profile pic and inside the APRS Settings. Why do two sets of these settings exist? It looks like only the BBS settings are used, but I think the APRS settings relate to the APRS-IS information, somehow, but it’s not really clear. If the APRS format is selected you would expect it to use the settings from that section of the app, but, it doesn’t.
- “Automatically Share Location” Should be under the APRS Settings or the BBS settings, or an all-encompassing “Data Settings” menu, not hidden inside the “General” menu under the settings wheel.
- “Automatically Share Location” channel should be labelled the “Data” channel – and used by default (or at least an option to) for all data related transmissions (messaging, digipeating).
- Digipeating Should be transmitted on the “Data” channel if one is selected
- Messaging should be transmitted on the “Data” channel if one is selected
- No Ability to properly set the APRS Path. Can only set it to WIDE1-1, or WIDE2-2, etc by the “Time To Live” setting. The most common paths used are WIDE2-1,WIDE1-1; WIDE2-1 and WIDE1-1 – it would be good to have options under the “Time To Live” for these paths as these are the most common used – or a fully custom free-text pathing option. Sometimes non-standard paths are needed, and every other APRS radio out there allows you to program a custom path
- Messaging should support standard APRS AX.25 messages and support the “ack” response so that duplicate messages don’t get received (As I understand it, the first part of this IS supported on Android).
- Object beacons from IGate or other stations show on the map with the callsign of the transmitting station – not the objects name.
- Object beacons show on the map with no comment information – repeaters are often transmitted over APRS so people know what’s in the area. Without the ability to view the comment information on the map we don’t know what frequency the repeater is on. Weather alerts are often carried by APRS to users in remote areas with no cell coverage – the radio should be able to alert the user of these alerts.
- The “Members” page doesn’t show the callsigns of the stations heard over APRS in the list, just a distance and time (Again, this may be different in the Android app, I’ve got had a chance to test it yet as I don’t have an android device that can connect to the radio).
- Digital squelch should have a higher threshold – can’t mute even weak interference
- APRS/Positioning transmit should be able to be inhibited (maybe an option) if the current receiving channel’s squelch is open.
- When I tap on the channel list in the top left corner, it would be nice to take me to the channel list menu.
- Some kind of S-Meter like in the android app.
- Channel Names under “Automatically Share Location” menu
- Fix “Null character” bug present in the symbol when sometimes sending position data.
- Read out the channels name label when switching channels via the microphone.
