rdunajewski

Try now!

Cost is TBD, but a notch duplexer is included with the RT97. It'll be everything you need to get a 5W repeater on the myGMRS network with the audio levels already set.

That's not us who replied, that's a different network that we have zero affiliation with. I think that's a pretty funny response! We can provide support but it's not a 100% plug-n-play operation. Since it's a Linux system, you'll need to know how to edit the configuration files to customize the node and set the audio levels. Generally speaking, once you set it up it's a hands-off thing. We just can't customize it to each and every repeater combination out there. We're going to offer a new version of the Retevis RT97 repeater with the linking bundle preconfigured for that in the near future, we're just waiting on the FCC certification and we'll begin placing orders for them. However, this is only a 5W repeater so it may not be for everyone's use case.

I'm not sure who told you that, but it's incorrect. We sell linking bundles that include almost everything you need to get onto our network: https://shop.mygmrs.com/collections/repeaters-and-accessories/products/repeater-linking-bundle The network is alive and well, growing every day: https://network.mygmrs.com/map

I have already looked into it, but there are no PTT signals anywhere inside. They use serial communications like I2C to command the radio IC to transmit, rather than use a logic signal. Without some serious, serious hacking, there's no way to add an ID board or external controller to these. However, I approached Retevis about this and they are making a version with an external connector on it. I have received the engineering samples and they work, although we may ask for some tweaks. Hoping to sell these on the store soon. We'll be able to sell an all-in-one linking bundle that is completely plug-n-play for the myGMRS Network.

You're right, but in the case of these small duplexers you can't just worry about the notch or you'll end up with a dummy load. The insertion loss is SO bad at 5 MHz split that you need to consider it, or you're burning 15W to get maybe 1W out of the transmitter (and your loss is also on the receive side, which isn't doing you any favors). So, it's really a balancing act between both of them. Filter the bad, but try to keep the good. Filter both, and what's the point?

No, I think there's no real reason to get vanity callsigns on GMRS. We'd probably all change our callsigns if we could, but it's just going to be chaos. Plus, don't forget, we share our callsign system with the Part 90 licenses (maybe others?). Just because it's vacant in GMRS doesn't mean you can pick it if it's assigned to a Part 90 station. I'm not sure if they are interleaved together by the FCC or if there's some "safe" ranges for GMRS use only, but I doubt that. We have a lot higher priorities that could use a Petition for Rulemaking like sorting out the Part 90 vs. Part 95 type certification and allowing digital voice emissions, in my opinion.

You do, but the insertion loss is caused by the fact that the "V" notch trough isn't the only factor. The insertion loss comes from what the filter is doing to the pass frequency, which on these small units is going to be much higher at a 5 MHz split than a 10 MHz split. So while you're filtering out 462.xxx MHz in the notch, you're also losing power on 467.xxx MHz due to the curve to the right. Basically you're too close to the notch, and you're losing some power there. This is also why the duplexers are marked with a high and low side, as the configuration of that curve to the left or right depends on which side you're on. Normally the insertion loss is small, like 1 to 1.5 dB on a good duplexer, but you don't have that low of curve to contend with in those cases. So to avoid this, you can either tune the V lower in frequency (which isn't great, as you're losing isolation) or you can try to make it a little shallower as long as you're still getting adequate isolation. Since it's a low power transmitter, you don't need -90 dB but the more isolation, of course, the better. It's just a balancing act to notch as much as you can without negatively impacting the frequency you want to pass. I had to retune the duplexers that came in an engineering sample I received of these repeaters, as they were tuned for 453 and 463 MHz. For one, I had to swap the high and low sides since they were set up with RX on 453 and TX and 463, which was an issue with the short SMA jumpers they included. Then, I had to retune the duplexers to the GMRS band and be careful to not impact the pass side too much. Keep in mind I'm no expert, my background is software not RF design or Electrical Engineering. I know just enough to be dangerous and convince myself I'm right most of the time. 🤓

Be careful with the fine tuning of the duplexer, you'll get it more accurate on the notch but you'll also end up increasing the insertion loss and the RT97 will put out less than 5W. Seems it's a 15W transmitter but the duplexer loss is folding back to 10W if you have the frequencies far enough apart or 5W if you're in the 5 MHz split range. If you get obsessive about the notch you might find out you're putting out 1-2W because of the insertion loss (that lower curved line).

Hi Walter, The callsign you posted is not a valid one. The format for newer callsigns is 4 letters and 3 digits, so it looks like that may be your issue.

I have fixed the issues with the license importing script. I never heard back from the FCC, so I had to put in a hack to pre-process the files looking for a certain case. WRMM237 and WRMN710 are both in the system now.

For the first point, there's a setting in your preferences where you can choose to jump to the latest unread message in a thread. I enabled it for myself since long threads could be a problem, you just want to see what's new. For the second point, unfortunately that's just an issue with the forum software we use. There's no control over that behavior that I have aside from modifying the core code, which isn't practical. Maybe there's an option for hiding that notification at the bottom so we only see them at the bell icon up top, that's something I'd be willing to check out.

Repeaters that haven't been updated in the last year are assumed to be "old" listings, so we hide them on the map to declutter the map of the repeaters that are probably not online anymore. It's a temporary fix, as we'll have a better way to report offline repeaters in the near future so we don't accidentally hide the old but still functional repeaters.

I'd rather not put in hacks like that, it adds a whole step to the process that is unnecessary. The output file is technically broken, so the fix needs to be done by the FCC. If they for some reason refuse, then we'll have to get more creative with it. It's also not a one-time fix, as this condition happens every week, and it won't be immune from another pipe character appearing in a field in the future, only this one specific case. Hopefully we hear back from them on Monday so we know the game plan.

We have a help desk ticket into the FCC about this. So some licenses are not getting ingested into our system, but others are okay. The data is there in the files they give us, but there's a critical problem preventing it that I believe they should fix. The FCC provides two types of database updates to us, a weekly "full" database copy, and a daily transaction file that contains only updates from the previous day (or 2 days if they're slower to update it). We use both, we use the full database to populate up until Sunday, then catch up to the current day by playing back the daily files since Sunday until we're caught up with what data they provide to us (which again, is still at least a day behind what you can search on their site). These files are a text format where each data field is separated by a pipe "|" character, and a new line for each new record. It's similar to CSV (comma-separated values) format but uses the pipe character instead since it's less common in a data field than a comma is. Whenever you have this separator character in the data set, you need to escape it somehow to tell the parser to ignore it as a field separator, usually with a backslash in front like "\|" or double quotes around the entire field. There is a certain license in the FCC system that appeared on April 27, 2021 for WRML255, that caused havoc in the data. There is a field for the title of the person signing the application for the GMRS license, and in this case the applicant entered "Owner|Operator" in this field. Here's what the FCC record shows: HD|4441017|0009519764||WRML255|A|ZA|04/27/2021|04/27/2031||||||||||N||||||||||N||Robert|A|Cecchino||Owner|Operator||||||||04/27/2021|04/27/2021||||||||||| Note how the pipe character is used to tell each field apart, and the number of fields must be predictable for us to know that field 3 or field 9 maps to a given field like a name or expiration date. The pipe character in "Owner|Operator" is not escaped by the FCC, so our software tries to split it into 2 fields, and keeps going down the row (but now we're mapping the rest of the fields off by one place), until we get to the last field. We expect 55 fields in each row, and we just detected a 56th field. Uh oh, parsing error! The FCC should escape the pipe character so it shows like so, as one example: HD|4441017|0009519764||WRML255|A|ZA|04/27/2021|04/27/2031||||||||||N||||||||||N||Robert|A|Cecchino||Owner\|Operator||||||||04/27/2021|04/27/2021||||||||||| Then we'll ignore it as a separator, and correctly detect 55 fields for this row. This case only appeared in one daily file in the past, so the next day it was okay and maybe a handful of licenses were affected. But when the full database comes around each week, this offending case is always there and it causes us to skip everything after this row. Your callsign is after this license, so you must not have been in a daily file for one reason or another (either the FCC missed it, or we couldn't fetch it on that day). You'll never appear in our system until this parsing error is fixed either on our end (with a real hack, very messy) or on the FCC's end, which I think is the correct place since this is a broken file, anyone else parsing it would have the same issue unless they put in their own hack to fix it. A hack is definitely not the right way to fix it from an engineering standpoint. If the FCC is able to commit to fixing it, perfect. It'll resolve itself once they fix the weekly database file. If they don't, then we have to find a reliable way to fix this and future cases, which is really suboptimal.