sds200 Over Limit

[kruser]

I cant find any specifics about the SDS100/200 internal memory size. So I will assume that it uses the SD Card similar to how a PC uses its hard drive, for storage purposes. It then loads what it needs from the SD card into its active internal memory (which of course has a limit, thus the FL max size limit). I notice that when FL lists are selected/deselected the SDS has to go through a loading process which also happens when settings are changed or when the scanner is powered ON/OFF. Whenever the scanner is powered of it "writes" any changes to the SD card to be recalled during the next power on sequence.

Or, I can be 100% wrong....

Trim any Favorite List down below 1 MByte is size and you will be fine.
That's the limit for favorite.

There was any uncertain limit on the amount of recording on a card that seemed to correspond to flaky or sporadic operation with ALL the SD card based Uniden models where they started acting slowly or erratic as in sudden reboots once the unknown amount of stored recordings was reached. I don't think anyone was ever to find a certain limit when this occurred though and if it had to do with the total file size of all recordings added together or simply just the number of recordings.
I don't record so have never had this problem. It does make me wonder though.

 

[W8RMH]

I would not hold my breath waiting for that to happen. There's a practical limit of how large a list the scanner's memory can handle. You're only going to bump into the 1mb limit if appending a huge statewide system, and/or adding thousands of UIDs. You'd end up with a oversized Favorites list that seemingly takes forever to scan, causing you to miss calls completely, or only catching the tail end of conversations, because the scanner had too much to wade through before running across an active talkgroup.

If you absolutely positively need to have such a large system (or collection of systems) be scanned at one time, just divvy it up between several favorites lists. If someone did that with multiple oversized lists, I'd just sit back and wait until they start a new thread complaining about scan speed and missed calls.

Scanners do not scan talk groups, they scan the control channel frequencies.

 

[kruser]

Scanners do not scan talk groups, they scan the control channel frequencies.

They also scan Sites and all frequencies associated with any entered sites. The also correctly scan talkgroups only like you said but any talkgroups or sites entered into a users Favorite list Will cause that list to grow in size.
Once the users size limit per favorite lists grows beyond 1 MB in size, the list can no longer be scanned.
My advice for very large systems is to trim down sites to only contain known CC frequencies and the alternates plus remove any talkgroups from across the state that you know you could never hear. This can be hard to understand for those new to trunking but it is the way it is.
Same for Sites, limit sites to your area, no way will you receive sites from across a state for example.

 

[Ubbe]

There was any uncertain limit on the amount of recording on a card that seemed to correspond to flaky or sporadic operation with ALL the SD card based Uniden models

They fixed that in the latest firmware. Keypresses are recognized instantly now and file handling like delete of a recorded 100 folder goes much quicker as well. It must be a new file handler for the SD card, maybe less integrity checking are done now whenever a file are touched.

/Ubbe

 

[buddrousa]

Folks also all you are doing in a FL buy packing full of things you can not hear in the first place is SLOWING DOWN YOUR SCANNER AND MISSING TRAFFIC.

 

[teknishun]

Just did a Firmware and Database update. All went well...until, I added one Talkgroup, from RR.
If I use the Favorites List with the new TG, I get an Over Limit screen note.

Thoughts of what is happening?

Thanks
Doug

WHAT!? I have the entire TxWarn database (ALL TGs) in my SDS-100 and SDS-200 duplicated 19 times (only the tower site is different
in each one) and I NEVER have had any space limitations. There are also about 30 other complete favorites lists as well.
Nowhere near the 1 Meg limit. I recognize I am limiting my available recording space but I seldom record stuff anyway.

My point is that there is PLENTY of room on that SD card for a BUNCH of TG and FL. Sounds as if you may have a corrupted
data file. I would try erasing all the current FL on the radio and then try downloading from Sentinel again.

Also, with that one additional Talkgroup are you perhaps mixing modes, such as DMR, analog, and P25 in the same list?

 

[teknishun]

Folks also all you are doing in a FL buy packing full of things you can not hear in the first place is SLOWING DOWN YOUR SCANNER AND MISSING TRAFFIC.

Packing bunches and bunches of TG in a FL does NOT slow down the scan rate. What slows down the scan rate is adding
too many sites to scan in the same list. It is the control channel decoding that slows down the scanner when you have several sites
in one FL. Those are best left split up. The TG list however is just a brief table lookup - it is either there or it isn't, but
the processor doesn't care one way or the other.

 

[buddrousa]

Like said adding things you can not hear like you said 150 sites from a state wide system for a base scanner or a mobile that may travel 60 miles from home 95% of the time

 

[ad5kl]

I split the Arkansas AWIN Troops A thru L on my scanner with Quick Keys. Each QK only contains sites within the associated Troop counties. A lot of the control frequencies are redundant throughout the state. Splitting down to Troop ensures the proper site is displayed as I scan.
I dumped all TG's into one bucket called "AWIN Wide" with an edited CSV import. The other number is for all county/city Analog systems within the Troop. As I travel, I switch over to the new Troop area Quick Keys.

Once Arkansas goes from P25 Phase I to Phase II, I will upgrade my BCD396XT to the SDS100.

 

[UnidenSupport]

Packing bunches and bunches of TG in a FL does NOT slow down the scan rate. What slows down the scan rate is adding
too many sites to scan in the same list. It is the control channel decoding that slows down the scanner when you have several sites
in one FL. Those are best left split up. The TG list however is just a brief table lookup - it is either there or it isn't, but
the processor doesn't care one way or the other.

It doesn't slow down the scan rate, but he has a point, as it increases your scan time. with a longer scan time you are more likely to miss transmissions.

 

[fdnyfish]

Some ham radio guys like myself would like to put in over 100,000 DMR I’d”s on a repeater system that works worldwide.

 

[wm8s]

I can only fit a fraction of TxWARN into a FL if I include the RID database [~80,000 RIDs]. I had to shave it way down [to 12,000 RIDs that I'm likely to hear] just to fit it into the 1 Mb FL limit.

...R

[TMI: Since my x36s don't also display the RID # if they have a RID name to display, I was including the RID # right-justified in the name; e.g.,

La Porte PD........3401100​

or

>Houston Fire NW...4499004 ​

[">" means it's a console]. Using that scheme, if I started with only the RIDs most likely to be heard SE [where I listen mostly, about 20,000 RIDs], then dump all of the CoH RIDs [about 6,000], I was still 1,000 over what fit in the 1 Mb FL limit. So I switched to putting the RID # at the beginning of the RID name; e.g.,

840 >CLEMC Pager​

or

3401100 La Porte PD​

It's uglier, but it saved a precious 50k.]