BCD436HP/BCD536HP: BCD436HP Discovery - bug report / feature request

[rumcajs_tr]

Hello,
while using my BCD436HP in Discovery mode, there is one thing which I would like to report as bug and one which I would like to suggest as new feature
The following text is mainly targeted to @JoeBearcat

BUG:
When using discovery, part of the setup is also to define Record Duration and the Time-out timer. The first one is the total audio record duration for a specific frequency, the second one is the maximum audio record duration for one "hit". Both these values are used to avoid the scanner being stuck on a particular frequency during Discovery and filling the SD card with audio only from one (or few) frequency.
To reproduce the bug, set the Record duration for example to 300sec and Time-out timer to 30sec (the values really don't matter). This should tell the scanner to record one frequency only for 5minutes max (300 sec) and one "over" should be max 30 seconds. After this, you would expect the scanner to skip the frequency, whet it hits it again and the timers are already full. But this is not true - the scanner stops on the frequency again, it doesn't record the audio, but still waits on the frequency as before until the Time-out timer expires... and again... and again. The only way how to solve this is to hit "L/O" and avoid this frequency manually - but this makes the Discovery useless when running unattended and you are not at home. I think the correct behavior should be that the scanner automatically avoids such frequency when the Record duration timer is full and the scanner should not stop on such frequency during this discovery run anymore

FEATURE REQUEST:
When using Discovery, it is not possible to link multiple search ranges in one discovery run - you can only select start and stop frequency. However, when you want to discover frequencies in larger frequency range, the situation usually requires you to split this range into multiple parts for three reasons - each part of the spectrum can have different mode, can have different step and there might be parts of the spectrum you want to skip. Is it possible to modify the discovery function in a way, that user can select from 1 to maximum of 10 custom search ranges (defined in custom search) and the discovery would link them together during discovery run.

I hope I made my findings clear (as English is not my native language) and that the bug can be easily reproduced (will probably affect also the BCD536HP and maybe the SDS100 and SDS200). I also hope that the explanation of feature request is understandable.

Regards, Ondrej

 

[JoeBearcat]

Both are feature requests. Recording timers were not designed to affect AVOIDs.

The first one is on the feature request list.

The second is not currently, but I will add it to the list.

 

[Ubbe]

FEATURE REQUEST: Is it possible to modify the discovery function in a way, that user can select from 1 to maximum of 10 custom search ranges (defined in custom search) and the discovery would link them together during discovery run.

That would be excellent if one could make that additional selection, to use the settings from search ranges 0-9 and of course that the compare to database/favorite list also was functional. Then the whole frequency spectrum could be checked for just new frequencies and not old ones already known.

/Ubbe

 

[Ubbe]

Recording timers were not designed to affect AVOIDs.

They where in HP-1 firmwares and in older firmwares for BCD536, pre DMR.

JoeBearcat, could you please make a new topic non-replyable, that only have your list and that you can edit and update? The same features requests and bug reports seem to come from different users in different threads as it is difficult to know what have already been reported.

/Ubbe

 

[JoeBearcat]

If it becomes really repetitive, yes. Currently my list is largely quotes from users and not presented in a concise list.

Also noted that the HP-x did AVOID based on the timers. I will move that one to the bug list.

 

[rumcajs_tr]

Both are feature requests. Recording timers were not designed to affect AVOIDs.
The first one is on the feature request list.
The second is not currently, but I will add it to the list.

Thank you for the feedback!

 

[rumcajs_tr]

... and of course that the compare to database/favorite list also was functional...

Now when I think about it, i remember that the "compare to database" function was working is one of the pre-DMR firmwares. However, it is broken now and doesn't work anymore, you are right.

 

[Saint]

Now when I think about it, i remember that the "compare to database" function was working is one of the pre-DMR firmwares. However, it is broken now and doesn't work anymore, you are right.

Yes the Compare to database and/or favorites list is not working, would be nice if that was fixed

 

[JoeBearcat]

Yes the Compare to database and/or favorites list is not working, would be nice if that was fixed

That has been looked into. No issue was found but it is possible the version of firmware used solved the issue since it was test firmware. For your cases, make sure your compare to was in active scan (available to be scanned if you were scanning). It will not compare to items not enabled.

 

[Saint]

I guess all the people who are saying that it's not working are wrong, the fact is it has been broke for a long time and nothing has been done

 

[JoeBearcat]

I guess all the people who are saying that it's not working are wrong, the fact is it has been broke for a long time and nothing has been done

Except for the fact that I posted a possible reason why that is.

I believe testing qualifies as "something".

 

[rumcajs_tr]

I will try to re-test the discovery function again with all FLs enabled. I don't use the global database. You may be right as the last time I did the discovery, I had most of the FLs disabled (QKs off) when I was doing last attempt.
Will report back this week with the results.

 

[rumcajs_tr]

OK, I couldn't resist and did some quick tests - here is what I did:

• I turned OFF all my FLs in the "Select lists to monitor" menu - the result is the famous "Nothing to scan"
• I created a new discovery run - 146-174MHz, step 12.5kHz, mode FM, delay=2s, Logging=ALL, Compare to database=ON, Record duration=30s, Time-Out timer=10s, Auto store=ON
• run this discovery once
• downloaded to Sentinel both the Discovery run result and also the new FL named "Conventional discovery"
• every frequency in the Discovery run was identified as "New found" - this is as expected.
• I went to the "Conventional discovery" FL and chose two frequencies and gave them names. The name "test1" was assigned to a frequency with CTCSS active and name "test2" was assigned to frequency without CTCSS. The rest of the frequencies were left with default (empty) names
• I wrote the "Conventional discovery" FL back to the scanner, enabled it and started another discovery run - the same settings except this time the Auto store = OFF
• I downloaded the results of discovery run back to scanner and reviewed the results. The frequency named "test1" was identified in Favorite list database and the name "test1" was assigned to it and the Known filed was populated with "Known". However the other frequency "test2" was not identified as known and no name was assigned to it even though it was in the discovery run result and it was still indicated as "New found".
• then I named another two frequencies in the "Conventional discovery" FL in Sentinel the "test3" and "test4" (the first one with ctcss and the second one without). Wrote the data do scanner and run discovery again with the same settings as the last time
• again, when downloaded the result, only frequencies "test1" and "test3" are identified as known and named properly. Frequencies "test2" and "test4" are not identified even though they are present in the discovery run - but identified as New found.
• Also no other frequencies are identified as "Known" no matter if they have CTCSS or not - as far as they have their default (empty) names.
• Later in the evening, I also test the above behavior with the DMR channel and CC instead of FM channel with the CTCSS - works the same.

So my current conclusion is this:

1. Discovery only identifies existing channels, which have names. The channels with default name are not identified as "Known" (no matter if they carry any CTCSS/DCS/NAC/CC or not).
2. Discovery only identifies channels with any CTCSS/DCS/NAC/CC active. The "plain" channels with no code are not identified even though they exist and have a name assigned.

Please, let me know if you ware able to reproduce this behavior.
I will be out of my home till Wednesday so I can do further tests on Thursday or Friday.
Regards, Ondrej

 

[JoeBearcat]

Does Test 3 and 4 have a CTCSS in reality? (over the air) - was one decoded?

 

[rumcajs_tr]

Test1 and test3 have ctcss in reality, test2 and test4 don't have it

EDIT: To make things clear... all frequencies are stored as in reality... when they have ctcss theay are stored with it, when they don't, they have Audio option set to "Search"

 

[JoeBearcat]

Thanks. That provides very useful info.

 

[rumcajs_tr]

No problem. Also, please don't forget about the feature request to allow linking multiple search ranges together in the Discovery as the current implementation with one range only is not of much use. Thanks for your support, regards,
Ondrej

 

[Ubbe]

Discovery only identifies channels with any CTCSS/DCS/NAC/CC active. The "plain" channels with no code are not identified even though they exist and have a name assigned.

Good find Ondrej!
I tested running old firmware in my 536, and when I did that earlier everything worked as expected with plain channels without any subtones. Channels that existed in database and FL's where muted and then skipped in discovery after a brief delay, probably to check for subtones.

When I tested now with old firmware it only works on the database and not with FL's. I used the same plain channels as in earlier tests that had no subtones. Also it did not skip the channels after the max recording time where reached when set to log Only New, as it did earlier and that the HP-1 does when tested now.

There's some bugs that make it work in unpredictable ways, the subtone and "plain" channel difference indicates that the code needs to be checked with a fine tooth comb.

edit: It worked as it should when I entered new channels into the Quick Save FL. Probably some incompatible issues with systems created in latest FW when used in older FW.

/Ubbe