• To anyone looking to acquire commercial radio programming software:

    Please do not make requests for copies of radio programming software which is sold (or was sold) by the manufacturer for any monetary value. All requests will be deleted and a forum infraction issued. Making a request such as this is attempting to engage in software piracy and this forum cannot be involved or associated with this activity. The same goes for any private transaction via Private Message. Even if you attempt to engage in this activity in PM's we will still enforce the forum rules. Your PM's are not private and the administration has the right to read them if there's a hint to criminal activity.

    If you are having trouble legally obtaining software please state so. We do not want any hurt feelings when your vague post is mistaken for a free request. It is YOUR responsibility to properly word your request.

    To obtain Motorola software see the Sticky in the Motorola forum.

    The various other vendors often permit their dealers to sell the software online (i.e., Kenwood). Please use Google or some other search engine to find a dealer that sells the software. Typically each series or individual radio requires its own software package. Often the Kenwood software is less than $100 so don't be a cheapskate; just purchase it.

    For M/A Com/Harris/GE, etc: there are two software packages that program all current and past radios. One package is for conventional programming and the other for trunked programming. The trunked package is in upwards of $2,500. The conventional package is more reasonable though is still several hundred dollars. The benefit is you do not need multiple versions for each radio (unlike Motorola).

    This is a large and very visible forum. We cannot jeopardize the ability to provide the RadioReference services by allowing this activity to occur. Please respect this.

A simple idea for "safe" scanning with an EDACS radio (800 MHz)

Status
Not open for further replies.

ElroyJetson

Member
Joined
Sep 8, 2002
Messages
2,506
Location
Florida, where you wish you were!
I just had a thought...maybe not for the first time, hopefully not for the last time. ;)


Though many of us know that an EDACS radio can be set to listen to a regular EDACS system
without affiliation or TX ability on any talkgroup, the possibility still remains that the system might
be able to command the radio if your LID gets hit.


I think I know a way around that.


An .sc4 file, which is custom built to offset the TX frequencies but leaves the RX frequencies alone.

The TX offset is 45 MHz on 800 systems. An .sc4 file that set a TX offset to any other value would be sufficient.


Just something to think about.


So who wants to try it?


Elroy
 
Joined
May 13, 2003
Messages
174
Location
Texas
If an EDACS radio doesn't affiliate (login) then the only reason that it might get disabled over the air would be if the programmed LID matched one the system admin wanted gone....so you need to program it with a LID that won't get used, or disabled. 0 is a great choice :)
 

mitaux8030

Member
Joined
Nov 21, 2005
Messages
269
Location
Home
My thoughts:
How would a .sc4 file that muddles up the TX freqs prevent it from being disabled?

With my experiences, for a radio that I want to keep 'off the radar', I've done the following:
Unticked auto-login
Disabled the Individual call menus /functions. I found that with this still enabled, and accessing those functions, a brief burst of RF (suspect HSD uplink, never really investigated it) is emitted despite auto-login disabled.
Likewise, disabled the WHC list... under some circumstances, I found a brief blat of RF could be emitted when using this.

That'll keep any RF from being transmitted. But it still won't stop a terminal from hearing any disruptive downlink commands... which is why I'm wondering how muddling with the TX freqs via an sc4 file would work. I've discovered a technique where a dynamic regroup targeting an LID, either known rogue or known 'unused' LIDs, can be redirected to a dead end group... and it'll stay there indefintely - effectively disabling the radio.
Of course, unticking dynamic regroup will prevent that from happening. So add that to your list of recommendations of keeping a radio active.
 

Radioman96p71

Member
Feed Provider
Joined
Jan 11, 2008
Messages
1,045
Location
Polk County, IA
Modifying the sc4 would definitely inhibit the radio from talking back to the system, but its that nasty "stolen radio" broadcast that is sent every 10 seconds on the control channel that can be a problem. Also, if the radio receives any kind of command to it, be it a remote EEPROM read, ProFile, Ping, or even OTAR, the radio will act on the command. Which I have seen first hand make a radio really upset when it hears the command but cant talk back. Setting the radio to LID 0 is an option, but then any data calls with a LID 0 destination will cause the radio to try and read them. Granted that is only if you have the data option and have it enabled for some weird reason. I guess the only true way to make these radios purely invisible would be to either find where the firmware hook is that listens for its ID and reacts, or find a way to put an impossible LID in the radio (like 16356+) so that it could never appear on the system. With hex-editing you might be able to make it happen.

For most systems and situations, simply turning all those features off and being careful will be good enuf. But if you are on a complex system or up against some good administration, you need to take extra precautions. :)
 

morganAL

Member
Joined
Nov 28, 2005
Messages
419
Location
Somerville, AL
I actually acquired a 500M mobile that someone had removed a resistor that was between the modulator and transmitter. Even if the Tx came up, it could NOT transmit the HSD. The only problem I can see with hex editing and assigning a LID over 16383 would be if you were monitoring an EDACS Extended Addressing system which can have over one million LIDs. However the only EA system I know is the State of Florida and it is all encrypted anyway so not really an issue.
 

ElroyJetson

Member
Joined
Sep 8, 2002
Messages
2,506
Location
Florida, where you wish you were!
There's a question: If you were to enable Extended Addressing while listening to a standard (Non-EA) system, would it receive properly?

I haven't tried that.

I'm not SURE about this, but my belief at the moment is that if a given radio were given an inhibit command, if it doesn't handshake with the controller and acknowledge the inhibit command successfully, it won't inhibit. That's why I'm wondering about messing with the TX frequency offset via an SC4 file. I'm THINKING that the radio's inability to actually exchange messages with the controller would keep the radio from being able to be inhibited. Can you shed any light on that?

Also, what's this about a stolen radio message every 10 seconds? Info, please.

Elroy
 

Radioman96p71

Member
Feed Provider
Joined
Jan 11, 2008
Messages
1,045
Location
Polk County, IA
I can answer the last 2 questions, If you run the program TrunkMon and check the last tab for system properties. It will show all disabled radios on the system and the flag set to them, around here they are all set to STOLEN_RADIO. Maybe thats the default, not sure. But if you watch the update interval, it happens every 10 seconds.

Also, a radio programmed to the LID of a STOLEN_RADIO will become locked and start TXing with an open mic, regardless if the transmitter is enabled or not. The only way to stop it is to clear the radio with Radio Maint and start from scratch.

No idea about the EA, as its not implemented here.
 
Joined
May 13, 2003
Messages
174
Location
Texas
There's a question: If you were to enable Extended Addressing while listening to a standard (Non-EA) system, would it receive properly?

I haven't tried that.

I'm not SURE about this, but my belief at the moment is that if a given radio were given an inhibit command, if it doesn't handshake with the controller and acknowledge the inhibit command successfully, it won't inhibit. That's why I'm wondering about messing with the TX frequency offset via an SC4 file. I'm THINKING that the radio's inability to actually exchange messages with the controller would keep the radio from being able to be inhibited. Can you shed any light on that?

Also, what's this about a stolen radio message every 10 seconds? Info, please.

Elroy
The answer to the EA/non-EA question is "yes" - the site ID message over-the-air is the same format, but indicates the protocol, so the radios auto-detect and switch. That was needed because they rolled Florida out as regular EDACS and converted it when it was up and running.

If a radio receives the "die now" message it'll die, period. The response back to the site simply means that the site removes the "die" message from it's queue and no longer sends it out. It only sends one (unacknowledged) response back, so it's quite possible the site will miss it. And that probably explains the "stolen radio" message thing too - as part of the background messages on the control channel there are a series of radio disable messages, repeated over and over until the radio gets killed or the system admin removes the radio from the death list.
 

ElroyJetson

Member
Joined
Sep 8, 2002
Messages
2,506
Location
Florida, where you wish you were!
So, one way to make a radio completely "safe" for scanner use is to set up the whole (regular) EDACS system as an EA system and assign a LID above 65535. The regular EDACS system won't ever know it's there or even be able to find it. Unkillable, and unworkable. But it makes a perfect scanner.


Very interesting indeed.


Elroy
 

edacsmaster

Member
Joined
Mar 31, 2007
Messages
7
radio as edacs scanner

on the J7100 that I have all I did was to disconnect the dc power to the PA deck
along with TX disable.
and using or programming the radio with systems test radio LID.
J,
 
Joined
May 13, 2003
Messages
174
Location
Texas
So, one way to make a radio completely "safe" for scanner use is to set up the whole (regular) EDACS system as an EA system and assign a LID above 65535. The regular EDACS system won't ever know it's there or even be able to find it. Unkillable, and unworkable. But it makes a perfect scanner.


Very interesting indeed.


Elroy
Sorry, but there are 2 LIDS - one for EA and one for EDACS. Depending on the protocol it chooses which one to use. That's not going to work.

If it were me, I think I'd chose a LID that was below 63, which is where all the system LIDs usually live.
 
Joined
May 13, 2003
Messages
174
Location
Texas
So you're saying that an EA system MUST have a standard address LID in additional to an EA LID?


If that's how it works, I guess I should warm up the soldering iron and yank the PA driver.


Elroy
Yep, that's how it works. The reason was that the State of Florida system was rolled out as EDACS, and only later converted to EA, so the radio code had to work on both, and switch seamlessly.

If you're planning on doing some soldering to make it safe, why not remove the write enable line on the EEROM chip?
 

mitaux8030

Member
Joined
Nov 21, 2005
Messages
269
Location
Home
why not remove the write enable line on the EEROM chip?
I guess that'd be fine if you never plan to change the config again and to never alter your scan groups or other such operator selectable variables - I'm pretty sure they get updated 'live' to the EEPROM too. Or does the EEPROM contents get dumped into a page of RAM and the RCP process operate on RAM during operation, only to later write any necessary changes to EEPROM eg during power down or a reset? Never delved that deep into the RCP/ICP or more modern equivalent processes.

One other thought... would disabling EEPROM write cause any self-diagnostic power up test to fail?

But some sort of write inhibit and some sort of TX disable (wether by the original proposal via an SC4 modification or by hardware modification) would be a robust method to keep a terminal off the radar while prolonging its utility as a receiver.
 
Status
Not open for further replies.
Top