[chirp_users] CHIRP 0.1.9b6

[Dan Smith]

> Even though CHIRP was displaying 00 - 25 as the initial range, it
> downloaded in excess of 800 memories (I'm guessing the 800 + 45 special
> mems), however it did not display all of the memories between 00 and 25
> as I would have expected.  It displayed 0 - 9 and then 16 - 21, followed
> by 34 - 37.  Everything else was missing, however when I looked at the
> debug log it had read 845 memories.

Right, that's the idea.  It's downloading them in the background if
there is nothing else to do.  It does this so that it has them cached in
case you want to look at, say, 90-100 a few minutes later.  In other
words, if you're not asking it to do anything else, why shouldn't it be
downloading the rest of the radio to have it ready in case you want it?

> I then looked at the contents of Mem 10 (on the radio) and it matched
> Mem 16 in CHIRP, likewise Mem 11 on the radio matched Mem 17 in CHIRP,
> etc.  I checked Mem 22 (on the radio) as the next break in the memory
> map and it matched Mem 34 on CHIRP.

Okay, I'm not sure I understand.  Are you saying that unused memory gaps
are resulting in an incorrect ordering in CHIRP?

> One other thing I noticed was that even though CHIRP downloaded the
> entire contents of Band A, without prompting when it was initially
> connected, if I instructed CHIRP to display 00 - 800, it would download
> the entire contents again.

Hmm, that's not the way it's supposed to work :)

One thing that may be throwing you off is that it (yet) doesn't cache
empty memories, so it will check the radio again to see if those have
been added.  Is this perhaps what you perceived as re-downloading the
memories?

If not, does it do this on Band B?  In all honesty, I rarely test with
Band A since Band B has more stuff to go wrong, so perhaps I broke
something with Band A specifically.

Thanks!

-- 
Dan Smith
dsmith#danplanet.com, s/#/@/
www.danplanet.com
KK7DS