?@ Skip,
Regarding the usefulness of the onboard USB, I wasnt sure what you had in mind for connectivity devices and if any of them other than a PC could natively connect to the USB.
I was thinking that the 2.4ghz radio was to be exterior anyway and the lines to I/F with it would have to exit the case somehow. There are the keyloader pins.......hang on donning the asbestos suit..........
Sound like you are all in on the SB9600 interfacing.
When I referred to "single ended", I should have said "not differential". There are points on the? option connector that look like they connect to circuitry in the radio that does the same job as the SN65176BP.
TTL TX/RX lines referenced to gnd, with busy (bidirectional signaling).
The reference to an outboard AT or PIC to handle the SB9600 commands was to hand off dealing with the busy line and send? properly timed pre-formatted packet(s) to trigger mode change/read EEPROM.
A simple "doit" command from the Pico via I2C was what I was thinking. Let the AT/PIC deal with any busy buss issues. Might be useful to monitor COS etc and I2C that back to the Pico as well.
If SB9600 is to play a bigger role than I was thinking, this would be unnecessary.....and does add another n MHZ clock to the inside of the radio case.
I think the Pico would be a perfect fit if we had just a bit more IO pins.
I believe the much (much) slower, and higher pricepoint MiniMega2560 has enough I/O for everything we want.
They are no Teensy for sure, but aree available, and half the price even if you could get a Teensy....and native 5v device to boot......
Tapping the LED and BootSel on the Pico does add complexity for those lacking that skillset, but so does soldering SMTs.
In for a penny, in for a pound I guess.
Working with old school parallel HW in a world that natively and almost exclusively speaks multi serial formats is the real challenge.
I dont care for serial/parallel anything either. It is messy, HW wise and code wise. The addr lines consumes so much of the I/O, it looks like our wants/needs are greater than our haves.
How are you invisioning loading the initial codeplug data and maintaining the configuration?
I've been tagging up on some things I've been putting off, but have taken a bit of time to research the PL side of this some more.
Because the RSS plays "cup and ball" games with the PL value storage, alterations made outside of the RSS will get wiped if any PL settings are modified with the RSS.
The behavior is difficult to pin down because the RSS moves around/deletes a lot of stuff when a value is edited/deleted.
Maintaining compatibility with how the RSS handles PL may be a challenge.
The other big thing is as far as I can tell, is the 16 MPL limit is operationally hard coded (in RSS?). Meaning it is possible to set any number of MPL but the storage area for the mode slaved PL values starts 16 tx/rx sets above the end of 16 MPL tx/rx sets.
Writing values to MPL 17 and up with the RSS begins overwriting the modeslaved PL data.
For maximum compatibility I've been working with a 2k codeplug image.
The RSS that is modified to allow 32 MPL only allows it for 8k images.
I have not determined if the overwriting issue exists with the 8k version.
I'm still not done exploring...as time permits.
