开云体育

This wasn't exactly a question, but: I'll point out that for the X, one of the very handy things about having an Xcat is that you don't need to unbutton the radio to fish out its code plug unit.

Good points. We really need to figure out how to get something usable from this LA data. I assumed for whatever reason, the radio just iterated over the mode data again and again refreshing itself to

Hi Skip, I wrote the Doug Hall RBI-1 firmware support for the S-COM 7K controller. I still get requests for RBI support on the S-COM 7330 -- I'm in the middle of implementing that now.? I have an

The Xcat does this with a fly-lead from the xcat to a point inside the radio, since the switching on the X is all mechanical. Note that the radio may or may not just read addresses n through

The M6 mode line is used, as you would expect. It basically ends up selecting which moby of the EPROM to access. The ways that 64 modes aren't really supported are largely related to the control

@ Casey, Unless your LA tests determined otherwise, I imagine the refresh is from data stored in the uC for that mode to the divider. Infact, that might explain a lot of the buss activity you were

Since the programming for this is a computed divisor, you can set any frequency you want within the range. On the X, the ranges are different for tx vs rx, or at least, since it uses different

64 modes is what the Syntor X could support (sort of, two independent banks of 32) from what I recall. As for the mad scientist in you ... no problem! 73's Skip

OK. I didn't know if the COS was in software or hardware. A limit search would be a great feature. I wish the scan could be made fast enough to emulate a GE MVS scan. It has Priority sampling so

I'll have to check my code again but I was able to drive the synthesizer very quickly across the band. Definitely fast enough for a good limit search function. The channel activity input to the

If scan is external you would also need a squelch indication in order to stop scan (for active channels). I would check to see how fast the synth can lock at maximum change (and lowest decode rate

As for the synthesizer the radio updates it every 20 milliseconds regardless of mode change to maintain stability in the event some transient voltage or whatever corrupted something. My thought was a

I agree with the baby step process, It is easier to interface to the X's hardware. Not that it matters with the Pico, but it runs a bit slower too. No SB9600 commands to deal with. Wirelrss UI and no

I have a Doug Hall unit and radio(s) if you need for testing. Jeff - KD6GDB

We had to have the black walnut tree removed from the back yard earlier this year, for Reasons. Significant reduction in Sciuridae. Might be worth a try. :) De

Good points! I had forgotten about needing to get the radio to re-read the mode info, ugh. In reality it might be worth taking this approach just to solve the refresh problem. An EXTERNAL to the

Going back to Skip's comment, a couple of thoughts, devil's advocate: 1. But you don't have to find a hack/slash way to get your control path out of the radio, because it's already there, and it's

@ Skip, True. Hand assembling a few basic commands like volume and mode select inc/dec, scan on/off etc might not be a major undertaking. I'd like to see a macro of commands that get you control of

After re-reading the txt a few additional thoughts.... The CE for the data line 245 must be an undefined (in the information presented) outboard connection to the host, probably an expansion window

I think the CPU *could* do it, but why bother? Plus playing with the state machine will be the fun part of the project for me. The "page zero" ram stuff really doesn't apply to the Teensy, it's a 32