Scan speed versus sensitivity

VK3KYY
Posts: 7486
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Scan speed versus sensitivity

Post by VK3KYY » Wed Mar 31, 2021 9:06 pm

G4EML wrote:
Wed Mar 31, 2021 9:35 am
Don’t forget that we have seen before that some radios had EEPROMs that were slow to write. We had to add the code to wait until the write was completed. Maybe speeding up the bus has caused the write to fail again.

Colin.
On my radio radio it was reading which fails when doing a factory reset

Adding a delay after writing seemed to fix it. But the delay seems to need to be a lot longer than the 5m in the Atmel data sheet.
My guess is the EEPROM chips in some radios are substandard clones, that won't work correctly unless the clocks speed is 1/10 the Max speed in the data sheet or perhaps the chip is not accessed for 50ms after the last write

VK3KYY
Posts: 7486
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Scan speed versus sensitivity

Post by VK3KYY » Wed Mar 31, 2021 11:48 pm

G4EML wrote:
Wed Mar 31, 2021 9:35 am
Don’t forget that we have seen before that some radios had EEPROMs that were slow to write. We had to add the code to wait until the write was completed. Maybe speeding up the bus has caused the write to fail again.

Colin.
I did some testing and there appears to be a few problems.

The system we use to wait for the EEPROM to finish its write, doesn't appear to work correctly.

The data sheet says that it takes 5 milliseconds to write any data and during that period the EEPROM will not respond to other requests.
We poll the EEPROM waiting for it to respond at 1 millisecond internals, but this doesn't seem to work if the bus speed is 400kHz.

Unfortunately changing the timing of this, causes another problem with the CPS, as the CPS won't work correctly if the firmware doesn't respond quickly.

I noticed this problem with the CPS over a month ago, mainly on Widows 10, which seems to behave slightly differently to Windows 7.
But to fix the CPS, the entire COM's transfer system needs to be rewritten to change it from polling for data from the COM port, to being event driven.

The code in the CPS is based on Kai's original COM's test code, which worked fine for his original testing, but is now becoming unusable.

But to rewrite the entire COMMS system is non trivial and will probably take several days of solid effort to complete, and at the moment I'm not keen to give up complete weekend's for things which are working, but not working in an optimal fashion.

VK3KYY
Posts: 7486
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Scan speed versus sensitivity

Post by VK3KYY » Thu Apr 01, 2021 11:37 pm

To try to improve the problem with the slow I2C bus speed, used by the EEPROM and the RF chip, I've now implemented a caching system for the RF chip commands.

https://github.com/rogerclarkmelbourne/ ... eed_v6.zip

This results in a 60% reduction in the number of commands being sent to the RF chip during scanning.

Scan speed in this version will still be slower than in the version 4 I posted last week, but the speed will still be better than it is in the last Beta version

User avatar
W1AEX
Posts: 126
Joined: Sat Nov 16, 2019 9:00 pm
Location: Connecticut, USA
Contact:

Re: Scan speed versus sensitivity

Post by W1AEX » Fri Apr 02, 2021 2:08 am

Hi Roger,

I've loaded the April 2 2021 v6 firmware into one of my GD77 radios and it is running fine. Seems plenty fast to me and I would not know it was slower if you had not said it is. I've only been running it for about 30 minutes but it seems to behave nicely while scanning analog and DMR channels. I'll give it a good run tomorrow.

73, and thanks for the new caching system release.

Rob W1AEX

VK3KYY
Posts: 7486
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Scan speed versus sensitivity

Post by VK3KYY » Fri Apr 02, 2021 2:21 am

Thanks Rob

I've tried to give the caching system a reasonable test myself on both DMR and FM including repeaters with CTCSS, and also using VOX which also seems to use the RF chip, and so far so good..

BTW.

I should have also said, that I've done an update to the voice prompts to include the audio for the 'Scan dwell time' and 'milliseconds'

https://github.com/LibreDMR/voice-promp ... 1.04.01.01

Some voices don't pronounce the word 'dwell' amazingly well, but most are OK.

ok1pt
Posts: 167
Joined: Mon Jul 20, 2020 3:38 am

Re: Scan speed versus sensitivity

Post by ok1pt » Fri Apr 02, 2021 3:12 am

Hello there,
I know that I'm coming late with it, but I just found it: It's a bit unforutnate that AT-D(57|86|87)8UV radios, which are also very popular on the HAM scene, uses the "Scan Dwell Time" for a totally different pupose. Quoting:
"Dwell Time: Only for analog use. When press PTT key to transmit, after release of the PTT key, the radio will resume scanning after reaching the Dwell Time."
I just hope that HAMs are clever enough to not get confused with this difference.
WIth regards & 73,
Pavel

VK3KYY
Posts: 7486
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Scan speed versus sensitivity

Post by VK3KYY » Fri Apr 02, 2021 4:57 am

ok1pt wrote:
Fri Apr 02, 2021 3:12 am
Hello there,
I know that I'm coming late with it, but I just found it: It's a bit unforutnate that AT-D(57|86|87)8UV radios, which are also very popular on the HAM scene, uses the "Scan Dwell Time" for a totally different pupose. Quoting:
"Dwell Time: Only for analog use. When press PTT key to transmit, after release of the PTT key, the radio will resume scanning after reaching the Dwell Time."
I just hope that HAMs are clever enough to not get confused with this difference.
WIth regards & 73,
Pavel
Possibly the dwell time of the other radios is equivalent to the existing "Scan delay" time.

Perhaps just call this "Scan time" or "Scan samp." for scan sampling time, as this the the duration it samples the S/N value on the frequency.

ok1pt
Posts: 167
Joined: Mon Jul 20, 2020 3:38 am

Re: Scan speed versus sensitivity

Post by ok1pt » Fri Apr 02, 2021 6:18 am

VK3KYY wrote:
Fri Apr 02, 2021 4:57 am

Possibly the dwell time of the other radios is equivalent to the existing "Scan delay" time.

Perhaps just call this "Scan time" or "Scan samp." for scan sampling time, as this the the duration it samples the S/N value on the frequency.
I believe it's one of the most logical variants which were already discussed. I'm voting for it.
Pavel

VK3KYY
Posts: 7486
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Scan speed versus sensitivity

Post by VK3KYY » Fri Apr 02, 2021 6:55 am

ok1pt wrote:
Fri Apr 02, 2021 6:18 am
VK3KYY wrote:
Fri Apr 02, 2021 4:57 am

Possibly the dwell time of the other radios is equivalent to the existing "Scan delay" time.

Perhaps just call this "Scan time" or "Scan samp." for scan sampling time, as this the the duration it samples the S/N value on the frequency.
I believe it's one of the most logical variants which were already discussed. I'm voting for it.
Pavel
Which one

"Scan time" ?

ok1pt
Posts: 167
Joined: Mon Jul 20, 2020 3:38 am

Re: Scan speed versus sensitivity

Post by ok1pt » Fri Apr 02, 2021 7:22 am

VK3KYY wrote:
Fri Apr 02, 2021 6:55 am
ok1pt wrote:
Fri Apr 02, 2021 6:18 am
VK3KYY wrote:
Fri Apr 02, 2021 4:57 am

Possibly the dwell time of the other radios is equivalent to the existing "Scan delay" time.

Perhaps just call this "Scan time" or "Scan samp." for scan sampling time, as this the the duration it samples the S/N value on the frequency.
I believe it's one of the most logical variants which were already discussed. I'm voting for it.
Pavel
Which one

"Scan time" ?
Either of them :-). But I believe that "Scan samp." is more descriptive, i.e. even a bit better than Scan time.

Post Reply