@ Skip,
Ah...good to know. I hope to spend a bit more time back on the "want to" list as well this weekend.
Seems the "need to" list insists on interfering with my "persuit of happiness" ....lol
|
Yes it's still looking promising. I haven't finished setting my X9000 yet so it's still untested. I'm planning on working on it this weekend. 73's Skip WB6YMH On Thu, Sep 15, 2022 at 4:59 AM swguest via groups.io <swguest@...> wrote:
On Fri, Sep 9, 2022 at 06:42 AM, Skip Hansen wrote:
At this point I think we know enough about the internal working of the
X9000 FW that we can control it STRICTLY over SB9600. I no longer think
we need to build a physical code plug replacement.
@ Skip,
...Just checking...
Is a pure SB9600 solution still looking promising or should I go ahead and tack the additional hardware items list to my Digikey order?
|
On Fri, Sep 9, 2022 at 06:42 AM, Skip Hansen wrote:
At this point I think we know enough about the internal working of the
X9000 FW that we can control it STRICTLY over SB9600.? I no longer think
we need to build a physical code plug replacement.
@ Skip, ...Just checking... Is a pure SB9600 solution still looking promising or should I go ahead and tack the additional hardware items list to my Digikey order?
|
>The idea is to hex edit the data for the "VFO" mode on the fly.? This
>is based on my current belief that single bytes in EEPROM can be
>written via SB9600.? This is the key.
If you can find a means to write select single bytes via SB9600 that will be a game changer. Even with expected re-writes in the 10k plus range before failure, I think VFO/FPP changes will wear hard on (presuming) mode 1 byte locations and even harder on the CS locations. The CS locations will be hit the most since it changes with every edit (unless you are REALLY lucky).
I've given some thought to a means similar to how the Spectra CS cheat is done? by doing differential CS calc and changing "some unused byte(s)" inside the CS field to value(s) that negate having to actually change the real CS.
At one time I loosly coded a differential CS calc The only test were POC for "the math". I never made any hardware POC tests. Too many other irons in the fire...
When we were "in the box" the wear could be easily managed since we could pull CS values from anywhere the code designated in the Pico's memory, and feed them to the radio uC on demand.If a location was to become unreliable or otherwise compromised, the code could be revised to revector to new locations for that address and it's good for another 10k plus writes. Rinse, lather, repeat as needed.
Yes parallel EEPROMs are still out there. When I started out looking at creating an FPP system for this radio I actually had in mind putting an SRAM on the bus to program and "swap in", leaving the OEM config as undisturbed as possible.
Yes it would need a battery to retain info when 5v (unswitched) is lost but based on my experience with Motorola Digicipher receivers and VC II sub boards, the backup batteries for the sub/UID data chips can last up to 20 years. I'm pretty sure that's not the battery I'll be worried about 20 years from now...lol ?
>So frequency / PL / DPL data comes into the "xcat 9k" via some means
>(Doug Hall, CI-V, keypad, morse code, DTMF, voice recognition...)
>which the"xcat 9k" converts to edits of the VFO mode via SB9600.
>Additionally the EEPROM checksum would be adjusted as needed.
>RSS could still be used in the usual manner.? It should be easy to
>write a new script to upload code plug binaries using a modern
>computer to avoid the timing issues with RSS.
>An ESP32 is certainly doable as easily or easier than a RPI Nano.
>
>For the record the 3 GPIO lines are for Busy in, Busy out and Write
>enable EEPROM (by grounding Mic high!).
>
>Of course additional GPIOs or serial ports (or Bluetooth radios or
>something) are needed to get information into the box on what to do!"
You left out "mind meld"..lol
Yeah, ATTinys might not make the cut for GPIO. I mentioned the ESP32 mostly because it had potential in the beginning. I've never messed with one so I cant speak to it's features or failings.
The RPI Pico may be overkill as well, but are super cheap. The Arduino Nano checks most of the boxes,size,GPIO and tried and proven Uno development so it is very versitile and lots of misc code snippets and routines "out there" that others have already worked out the function(s).
Price point is => than the ESP32 for a lot less horsepower and features though.
Truth is, once(if) the SB9600 routines are mastered sufficiently a UI/"client" to the Xcat9k can be platform independent and as complex or simple as needed.
??
>Reprogramming mode names in the control head might be doable, but as
>with the radio the code plug format would have to be understood first.
>I've been disassembling the radio's firmware to understand things.
>I'm not sure how accessible the control head firmware is ... it isn't
>EPROM based is it?"
Yes there are EEPROMs for FW and "codeplug" data. The chip package and memory size depend on which model. The 1033 series was the earlier gen workhorse and probably the most popular. They have 28C16 or optional 28C64 EEPROMs for the CP data. Mike B.'site has a great breakdown of System 9000 stuff.
?Maratracs use a 1032(?) I think it is. Same clamshell/similar look...DO NOT CONNECT to your X9000! It is completely different inside.
I've only breifly looked at a .CDT in hexview.
IIRC, the alpha tags for mode names and MPL are in plain text. I dont know if the starting point is static and fixed to a given mode/MPL but if so, byte level editing of these parameters should be trivial if SB9600 support is sucessful. As you said the codeplug layout is TBD.
I suspect the CS exisits and is similar in nature to the .RDT files ?
Button/function assignment, VIP programming, etc would require real RSS or a much more complex set of routines than would be needed to edit some ASCII values.
I'm of a mind that a? full-fledged replacement for the RSS is a project all in itself. ?
>BTW Much to my total shock and amazement AT28C64 EEPROMS in a DIP
>package are still
>readily available!? Both Mouser and digikey have them in stock for around $6."
Yeah, that does surprize me too, considering the "chipdemic" has shorted so much of the other components. Must be a serious surplus of the DIP stuff yet to be used.
That kind of stuff and more like it is always on Ebay too. I think most of that is salvaged from crap we dumped on China or ex eastern block countries that arent under RoHS directives.
I've always been quite the PCB scrounger. Before I retired, electronic recycling (aka E-waste) came thru our shop for evaluation. Guess who got to dig in the "scraps" before they met their doom?
I got to pick thru lots of boards etc, saving EEPROMs and SRAMs and such with "potential" from their untimely demise...lol
|
Hi Stan, The idea is to hex edit the data for the "VFO" mode on the fly. This is based on my current belief that single bytes in EEPROM can be written via SB9600. This is the key. So frequency / PL / DPL data comes into the "xcat 9k" via some means (Doug Hall, CI-V, keypad, morse code, DTMF, voice recognition...) which the"xcat 9k" converts to edits of the VFO mode via SB9600. Additionally the EEPROM checksum would be adjusted as needed. RSS could still be used in the usual manner. It should be easy to write a new script to upload code plug binaries using a modern computer to avoid the timing issues with RSS. An ESP32 is certainly doable as easily or easier than a RPI Nano. For the record the 3 GPIO lines are for Busy in, Busy out and Write enable EEPROM (by grounding Mic high!). Of course additional GPIOs or serial ports (or Bluetooth radios or something) are needed to get information into the box on what to do! Reprogramming mode names in the control head might be doable, but as with the radio the code plug format would have to be understood first. I've been disassembling the radio's firmware to understand things. I'm not sure how accessible the control head firmware is ... it isn't EPROM based is it? 73's Skip WB6YMH BTW Much to my total shock and amazement AT28C64 EEPROMS in a DIP package are still readily available! Both Mouser and digikey have them in stock for around $6. On Fri, Sep 9, 2022 at 12:43 PM swguest via groups.io <swguest@...> wrote:
@ Skip,
That definately sounds revolutionary. As you might guess that creates a number of followup queries.
I am looking forward to hearing your POC testing criteria and results..
Control, as in a subtitute/replacement for PC based OEM RSS for block writes to the EEPROM (RSS emulation) and/or byte level writes equating to a form of direct EEPROM writes to effect FPP freq/PL control?
I did see EEPROM block writes by emulating RSS on a non PC platform comming.
I never gave thought to byte level writes using SB9600. I allways perceived it as a"write complete codeplug data to EPROM" routine.
Some are hoping for a replacement for the CH.
Mastering the SB9600 could lead to that as well, or at least enhancing some of it's operations.
Presuming the CH is retained, I guess another step would be to be able to re-program mode/MPL names in it as well with the same SB9600 setup.
With client side HW to be "almost anything with a serial port", depending on the complexity of th UI, that should put minimalist builds of the 16F8s, ATMega328s, etc back in the running.
Low GPIO count adds the ATTiny stuff to the list as well.
Actually since we are literally talking "outside the box" now, that brings us back to a closer look at the ESP32 w/built in 2.4g WiFi potential.
Not to mention the matter of a UI open to a variety of display and data entry configurations.
Beyond a basic UI, users could, if desired, develop a custon UI that fits their needs. Probably not as easy as building a Winamp "skin", but doable nontheless.
I do have a couple of those RIB clones.I have no complaints with them. Issues I've had using them was user error.
I checked Ebay and it looks like they are still in the 20-30 dollar range.
I know there is still much TBD, but I admit this has the potential to open a bunch of doors.
My mad scientist hat is beginning to smolder....
It is hard to think about giving up on a good old-fashioned hardware hack though....
|
@ Skip,
That definately sounds revolutionary. As you might guess that creates a number of followup queries.
I am looking forward to hearing your POC testing criteria and results..
Control, as in a subtitute/replacement for PC based OEM RSS for block writes to the EEPROM (RSS emulation) and/or byte level writes equating to a form of direct EEPROM writes to effect FPP freq/PL control?
I did see EEPROM block writes by emulating RSS on a non PC platform comming.
I never gave thought to byte level writes using SB9600. I allways perceived it as a"write complete codeplug data to EPROM" routine.
Some are hoping for a replacement for the CH.
Mastering the SB9600 could lead to that as well, or at least enhancing some of it's operations.
Presuming the CH is retained, I guess another step would be to be able to re-program mode/MPL names in it as well with the same SB9600 setup.
With client side HW to be "almost anything with a serial port", depending on the complexity of th UI, that should put minimalist builds of the 16F8s, ATMega328s, etc back in the running.
Low GPIO count adds the ATTiny stuff to the list as well.
Actually since we are literally talking "outside the box" now, that brings us back to a closer look at the ESP32 w/built in 2.4g WiFi potential.
Not to mention the matter of a UI open to a variety of display and data entry configurations.
Beyond a basic UI, users could, if desired, develop a custon UI that fits their needs. Probably not as easy as building a Winamp "skin", but doable nontheless.
I do have a couple of those RIB clones.I have no complaints with them. Issues I've had using them was user error.
I checked Ebay and it looks like they are still in the 20-30 dollar range.
I know there is still much TBD, but I admit this has the potential to open a bunch of doors.
My mad scientist hat is beginning to smolder....
It is hard to think about giving up on a good old-fashioned hardware hack though....
|
Hi Stan,
At this point I think we know enough about the internal working of the X9000 FW that we can control it STRICTLY over SB9600.? I no longer think we need to build a physical code plug replacement. What I am envisioning now is some C code that'll run on almost anything with a serial port and 3 GPIO lines wired to a RIB box.? I'll do a proof of concept on the Nano and others can port the code to Arduinos or whatever. The cheapish Chinese RIB clones on ebay come in a black plastic box which includes provisions for a 9 volt battery.? Interestingly the Raspberry Pi Nano is about the same size as a 9 volt battery and it fits nicely ! ?
I am dying to get my test bench setup to start testing the concept. ?I
just received my control head and it appears to work. Next I need to build
a RIB cable and start wiring things up.
I'll keep the group updated as things progress, stay tuned!
73's Skip WB6YMH
@ Skip,
I'm intrigued. Fourtunately, I picked up a Pico to "stash" on an order previous to this project starting because it was an unbelievable deal. I plan to grab a few more on the next order "just because"...lol
The balance of the order was for some DDS experimenting I've been thinking on for a while now too, so there's no rush to order for sure.
Anyone who has had the XYL experience can attest "Happy wife, happy life" is not just an adage, it's gospel.
It looks like Cali is slow to loosen it's grip so enjoy what you can where you can.
From the time I began to dig in to what makes these things tick, I have thought about several hardware intensive additions and modifications, but they are well beyond a "Plug n Play" project most users would be interested in doing.
I am looking forward to an update on what you've got in mind.
|
@ Skip,
I'm intrigued. Fourtunately, I picked up a Pico to "stash" on an order previous to this project starting because it was an unbelievable deal. I plan to grab a few more on the next order "just because"...lol
The balance of the order was for some DDS experimenting I've been thinking on for a while now too, so there's no rush to order for sure.
Anyone who has had the XYL experience can attest "Happy wife, happy life" is not just an adage, it's gospel.
It looks like Cali is slow to loosen it's grip so enjoy what you can where you can.
From the time I began to dig in to what makes these things tick, I have thought about several hardware intensive additions and modifications, but they are well beyond a "Plug n Play" project most users would be interested in doing.
I am looking forward to an update on what you've got in mind.
|
Hi Stan, I actually have a new idea that I haven't shared yet. Hold off on everything other than the Pico for now. I don't have time to elaborate at the moment, my wife is waiting for me to go out. I'll have an update later. 73's Skip WB6YMH On Thu, Sep 8, 2022 at 1:05 PM swguest via groups.io <swguest@...> wrote:
@ Skip,
I'm making up a Digikey order list.
I've got other non X9000 related stuff to get, so I figured to make one "complete as possible" order and save on shipping.
I am presuming your KiCad files are general/draft at this point, and actual board design and layout is still undefined.
The reason I mention this is that the SN74LV244APW is a TSSOP package with a finer pitch over the pinout equivalant, wider pitched SN74LV244ADW in the SOIC package.
At this pincount, density of the SOIC is 2x a PDIP, where the TSSOP is 4x the density of a PDIP package.
There does not appear to be a PDIP equivalant for the SOIC packaged SN74LV02. LS yes, LV no.
The SN65176BP appears to be a thru hole PDIP. I socket all PDIPs if possible.
The BSS138 are SMT but the solder points are far enough apart and shouldnt be an issue either. The BS170 appears to be the thru hole equivelant but NA at Dighkey. Jameco has plenty but if that's all that was ordered, min shipping would not be worth it
You didnt call out the Schottky feeding the VSYS but a thru hole device that may be usable is the 1N5820.
The pullups and bypasses I'd like to see in thru hole as well.
Also, did you intend to use a bypass cap on the SN65176BP?
J3 appears to be a 2x6 IDC (male?) headr connector like/similar to the one used on the Xcat.
Rather than task the original EEPROM socket's Vcc point with supplying the new assy, I would recommend a different feedpoint via a (1x2 or more) IDC connector dedicated and bypassed for power.
Space permitting, the "or more" to be unused pins for potential future "flying connection" board interconnect(s).
The 5v feed would be from a (TBD) source on the personality board via "flying lead(s)".
Given the ability, I would also make the Pico "pluggable" on pins.
If there is (ever) a problem, it would make for easier diagnostics, repair and/or replacement.
The Pico's 133mhz clock may require sheilding/RF bypassing and being "on pins" may help to easily add this to the design if needed.
So far Digikey has everything I as looking to order, but my list is not complete
|
@ Skip,
I'm making up a Digikey order list.
I've got other non X9000 related stuff to get, so I figured to make one "complete as possible" order and save on shipping.
I am presuming your KiCad files are general/draft at this point, and actual board design and layout is still undefined.
The reason? I mention this is that the SN74LV244APW is a TSSOP package with a finer pitch over the pinout equivalant, wider pitched SN74LV244ADW in the SOIC package.
At this pincount, density of the SOIC is 2x a PDIP, where the TSSOP is 4x the density of a PDIP package.
There does not appear to be a PDIP equivalant for the SOIC packaged SN74LV02. LS yes, LV no.
The SN65176BP appears to be a thru hole PDIP. I socket all PDIPs if possible.
The BSS138 are SMT but the solder points are far enough apart and shouldnt be an issue either. The BS170 appears to be the thru hole equivelant but NA at Dighkey. Jameco has plenty but if that's all that was ordered, min shipping would not be worth it
You didnt call out the Schottky feeding the VSYS but a thru hole device that may be usable is the 1N5820.
The pullups and bypasses I'd like to see in thru hole as well.
Also, did you intend to use a bypass cap on the SN65176BP?
J3 appears to be a 2x6 IDC (male?) headr connector like/similar to the one used on the Xcat.
Rather than task the original EEPROM socket's Vcc point with supplying the new assy, I would recommend a different feedpoint via a (1x2 or more) IDC connector dedicated and bypassed for power.
Space permitting, the "or more" to be unused pins for potential future "flying connection" board interconnect(s).
The 5v feed would be from a (TBD) source on the personality board via "flying lead(s)".
Given the ability, I would also make the Pico "pluggable" on pins.
If there is (ever) a problem, it would make for easier diagnostics, repair and/or replacement.
The Pico's 133mhz clock may require sheilding/RF bypassing and being "on pins" may help to easily add this to the design if needed.
So far Digikey has everything I as looking to order, but my list is not complete
|
Hi Brad, No you need to flash it the first time using a programmer. What I probably did was use the programmer to flash the loader and some old version of the application then I updated to the current version of the application to test the serial interface. I misled you due to a memory parity error (girn). 73's Skip WB6YMH On Mon, Sep 5, 2022 at 7:26 AM Bradley Andrews via groups.io <kb9bpf@...> wrote:
Hi Skip, and thanks for the encouragement.
Let me ask you simply, should the Xcat application software be used to upload the firmware when only the bootloader is programmed on the PIC?
If so, then something here isn't working. (Probably me...) I've been looking through my old files for the old MPLAB software but I'm not finding it. The computer I used back in '09 when I was dabbling in this stuff crashed long ago but I usually am pretty thorough at archiving software and projects.
Thanks,
Brad
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Skip Hansen
Sent: Monday, September 05, 2022 8:36 AM
To: [email protected]
Subject: Re: [xcat] DIY Xcats
Hi Brad,
I think you've figured it out. There are lots of lost bits in my
memory, but reading the comments in the bootloader code it appears
that it expects the application to have put a jump to the start of the
application at address 0x02. That's not how I would have done it
today, but there may be reasons that I've forgotten.
The source for the bootloader is fairly well commented and is
available here:
--- snip ---
;Simple Intel hex loader/programmer.
;
;Programs a line at a time is into flash and then sends a single character
;response (following receipt of a carrage return). Host software must wait
;for the response before sending the next line.
;
;Loader is entered by holding the serial line in a space state while the
;PIC is turned on (or reset). If the serial line is in a mark state
;immediately after reset the normal application code is run.
;
;Modifications to application program to use loader:
; 1. Start startup at address 2 rather than zero.
; 2. Start application code after the end of loader.
; 3. Ensure only addresses below end of loader programmed by hex file
; are 2 (start vector), 3 and 4 (interrupt vector)
;
;Response after receiving a carrage return character:
;'B' - Begin sending (first line, no prior status to report)
;'P' - Programmed data Ok
;'E' - program Error
;'C' - Checksum error
;'S' - Syntax error (non-hex digit received)
;'I' - last record type Ignored
;'F' - Finished ... jumping to application
;'R' - program address out of range (probably the configuration word),
; record ignored.
--- snip ---
Good luck! We're all waiting on the edge of our chairs to hear if it
works or not!
73's Skip WB6YMH
On Mon, Sep 5, 2022 at 1:11 AM Bradley Andrews via groups.io
<kb9bpf@...> wrote:
Skip,
I have a question about programming, but first some background and a progress report:
- A couple weeks ago, after I’d gotten my boards, I programmed a PIC with picldr.hex using my Phyton ChipProg-40 and the DIP-to PLCC adapter. When I tried to connect the PC to upload the rest of the firmware through the Xcat PC software, it didn’t work, getting stuck waiting for the download request from the Xcat.
- So, I’ve built a programming adapter and had a go at it again. The programmer says the PIC programs OK and verifies OK. Then I try a read and it comes back all 0000. A re-verify comes back all 0000.
- I did some more reading, pulling down books that I haven’t looked in for 13 years. So it’s looking like the protect bit is set in the config register. I didn’t find - until just now as I’m thinking better (after some rest) - the place in the Phyton to set the device config.
- I found that the picldr.hex file puts 1F76 in location 2007, the config register, which sets the memory protection. I turned it off in the config and changed location 2007 in the program buffer and could read back the (now modified) picldr.hex code I programmed, but when I put the PIC in the Xcat in the Syntor X, and attempted to use the Xcat PC software to upload the v033 firmware, it still wouldn’t go past the stage of waiting for the download request from the Xcat even after power-cycling the radio.
So now my question to you, Skip, is this: What am I doing incorrectly? To quickly summarize what I’ve been doing: flash the picldr, then attempt to use Xcat PC to upload the v033 firmware.
Oh and FYI, the config bits are not OTP: they can be changed if you run a complete erase. So at least I’m not trashing $9 PICs while I learn.
Once I figure out how to correctly get the PICs programmed, I’ll be able to verify the proper function of the PCB, and then I’ll be able to share the fruits of my labors. I think I’m just missing some small but essential piece of the programming puzzle.
Thank for the help,
Brad KB9BPF
From: [email protected] [mailto:[email protected]] On Behalf Of Bradley Andrews via groups.io
Sent: Saturday, August 20, 2022 10:22 PM
To: [email protected]
Subject: Re: [xcat] DIY Xcats
I was writing the other while you were writing this. Sounds like I may have to build a programming adapter access the appropriate pins on the Xcat, like you did.
I need to have a think on it and do some reading so that I don't bother you or the group with my ignorance When I have more intelligent questions I'll come back. Thanks for your willingness to help!
73
Brad KB9BPF
On Saturday, August 20, 2022, 10:06:42 PM CDT, Skip Hansen <skip@...> wrote:
Hi Bradley,
It should be possible to combine the two hex files by just deleting
the end of file line in one and then appending the contents of the
other. On the other hand, just flashing both of them sequentially is
probably way easier than screwing around combining the files. Just
make sure you aren't doing a whole chip erase twice (grin).
The bootrom's hex file should contain the values for the PICs
configuration bits as well as the code. The configuration bits are
one time programmable if I remember correctly and they are not in the
application image. If the configuration bits aren't correct the
oscillator won't even startup.
73's Skip
On Sat, Aug 20, 2022 at 7:24 PM Bradley Andrews via groups.io
<kb9bpf@...> wrote:
Hi Skip, and thanks for the tips.
Yes, I did include the extra SIP resistor network. I also changed the two smaller SIPs to a single SOIC resistor network, included a couple extra bypass caps, and scooted things around slightly for space. And I changed the resonator to an SMT.
I'm attempting to attach a PDF of the schematic and the artwork for perusal. Only when I have confirmed that the circuit boards work will I post the ExpressPCB files. I don’t remember of this group allows attachments or not, but I'll try it.
Regarding programming, when you say "The two steps aren't necessary; you can flash everything in one go if you combine the hex files. I did it that way to test the serial port." Do you mean an overlay of the two? I haven't looked at PIC programming for a long time, and only did a couple easy things when I did do it. Back then I used a serial programmer from MBasic, if I remember correctly, and it used standard DIP sockets. I thought I'd use the Phyton because it I have a PLCC adapter for it, but it's made for the ZIF DIP socket on the Phyton, not regular DIP sockets. I'll have to get out the PIC docs again and study up on programming requirements before I waste a lot of people's time and patience asking questions I should figure out on my own.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Skip Hansen
Sent: Saturday, August 20, 2022 7:45 PM
To: [email protected]
Subject: Re: [xcat] DIY Xcats
On Sat, Aug 20, 2022 at 4:53 PM Bradley Andrews via groups.io
<kb9bpf@...> wrote:
Hi Skip,
Thank you for giving your blessing to those of us who are brave/crazy in this way. I’ve wanted to do this for some time but didn’t want to step on your (or Lee’s) toes.
Would you mind answering a couple questions for me?
1. How did you guys program your PICs? Did you do it in a stand-alone programmer before soldering to the PCB, or did you do it via the RS232 serial port on the Xcat?
Neither. The programming pins are available via a combination of the
accessory cable and the connector normally connected to the Syntor. I
connected the necessary pins to a PIC programmer and programmed the
bootloader. Once the bootloader has been programmed I flashed the
application firmware via the serial port. The two steps aren't
necessary; you can flash everything in one go if you combine the hex
files. I did it that way to test the serial port.
2. Regarding the Xcat firmware, xcat_v033/xcat.hex, if I wanted to program it in my standalone programmer before soldering, would I use ‘Standard/Extended Intel HEX (*.hex, *.mcs)’ whose checksum comes to 001EA2F4, or force it to read in Binary whose checksum is 000CF1CF? I don’t want to do it incorrectly and not find out until the PIC is soldered in place.
You need to program the bootloader first. In addition to the
bootloader itself there are configuration bits which are needed.
FYI, my programmer is a Phyton ChipProg-40.
I don't recall what my programmer was. It wasn't a Microchip product
and the company that made it when out of business long ago. If your
programmer supports the chip it should be fine.
I like ExpressPCB and that’s what I used to lay out my Xcat ‘clone’ boards. If it works, and I expect it will, I’ll have some spares available if anyone is interested in obtaining them (at my cost) and using them to assemble their own. I’ll also be happy to upload the ExpressPCB .sch and .pcb files to the file section of this group, if you give that your blessing, Skip. I’d be willing to provide programmed PICs for those who are interested, as well as the other parts, but only with your blessing, Skip.
That would be EXCELLENT !
Hopefully you've added the pullup resistors that we forgot !
73's Skip WB6YMH
|
Hi Skip, and thanks for the encouragement.
Let me ask you simply, should the Xcat application software be used to upload the firmware when only the bootloader is programmed on the PIC?
If so, then something here isn't working. (Probably me...) I've been looking through my old files for the old MPLAB software but I'm not finding it. The computer I used back in '09 when I was dabbling in this stuff crashed long ago but I usually am pretty thorough at archiving software and projects.
Thanks,
Brad
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] [mailto: [email protected]] On Behalf Of Skip Hansen Sent: Monday, September 05, 2022 8:36 AM To: [email protected]Subject: Re: [xcat] DIY Xcats Hi Brad, I think you've figured it out. There are lots of lost bits in my memory, but reading the comments in the bootloader code it appears that it expects the application to have put a jump to the start of the application at address 0x02. That's not how I would have done it today, but there may be reasons that I've forgotten. The source for the bootloader is fairly well commented and is available here: --- snip --- ;Simple Intel hex loader/programmer. ; ;Programs a line at a time is into flash and then sends a single character ;response (following receipt of a carrage return). Host software must wait ;for the response before sending the next line. ; ;Loader is entered by holding the serial line in a space state while the ;PIC is turned on (or reset). If the serial line is in a mark state ;immediately after reset the normal application code is run. ; ;Modifications to application program to use loader: ; 1. Start startup at address 2 rather than zero. ; 2. Start application code after the end of loader. ; 3. Ensure only addresses below end of loader programmed by hex file ; are 2 (start vector), 3 and 4 (interrupt vector) ; ;Response after receiving a carrage return character: ;'B' - Begin sending (first line, no prior status to report) ;'P' - Programmed data Ok ;'E' - program Error ;'C' - Checksum error ;'S' - Syntax error (non-hex digit received) ;'I' - last record type Ignored ;'F' - Finished ... jumping to application ;'R' - program address out of range (probably the configuration word), ; record ignored. --- snip --- Good luck! We're all waiting on the edge of our chairs to hear if it works or not! 73's Skip WB6YMH On Mon, Sep 5, 2022 at 1:11 AM Bradley Andrews via groups.io <kb9bpf@...> wrote:
Skip,
I have a question about programming, but first some background and a progress report:
- A couple weeks ago, after I’d gotten my boards, I programmed a PIC with picldr.hex using my Phyton ChipProg-40 and the DIP-to PLCC adapter. When I tried to connect the PC to upload the rest of the firmware through the Xcat PC software, it didn’t work, getting stuck waiting for the download request from the Xcat.
- So, I’ve built a programming adapter and had a go at it again. The programmer says the PIC programs OK and verifies OK. Then I try a read and it comes back all 0000. A re-verify comes back all 0000.
- I did some more reading, pulling down books that I haven’t looked in for 13 years. So it’s looking like the protect bit is set in the config register. I didn’t find - until just now as I’m thinking better (after some rest) - the place in the Phyton to set the device config.
- I found that the picldr.hex file puts 1F76 in location 2007, the config register, which sets the memory protection. I turned it off in the config and changed location 2007 in the program buffer and could read back the (now modified) picldr.hex code I programmed, but when I put the PIC in the Xcat in the Syntor X, and attempted to use the Xcat PC software to upload the v033 firmware, it still wouldn’t go past the stage of waiting for the download request from the Xcat even after power-cycling the radio.
So now my question to you, Skip, is this: What am I doing incorrectly? To quickly summarize what I’ve been doing: flash the picldr, then attempt to use Xcat PC to upload the v033 firmware.
Oh and FYI, the config bits are not OTP: they can be changed if you run a complete erase. So at least I’m not trashing $9 PICs while I learn.
Once I figure out how to correctly get the PICs programmed, I’ll be able to verify the proper function of the PCB, and then I’ll be able to share the fruits of my labors. I think I’m just missing some small but essential piece of the programming puzzle.
Thank for the help,
Brad KB9BPF
From: [email protected] [mailto:[email protected]] On Behalf Of Bradley Andrews via groups.io
Sent: Saturday, August 20, 2022 10:22 PM
To: [email protected]
Subject: Re: [xcat] DIY Xcats
I was writing the other while you were writing this. Sounds like I may have to build a programming adapter access the appropriate pins on the Xcat, like you did.
I need to have a think on it and do some reading so that I don't bother you or the group with my ignorance When I have more intelligent questions I'll come back. Thanks for your willingness to help!
73
Brad KB9BPF
On Saturday, August 20, 2022, 10:06:42 PM CDT, Skip Hansen <skip@...> wrote:
Hi Bradley,
It should be possible to combine the two hex files by just deleting
the end of file line in one and then appending the contents of the
other. On the other hand, just flashing both of them sequentially is
probably way easier than screwing around combining the files. Just
make sure you aren't doing a whole chip erase twice (grin).
The bootrom's hex file should contain the values for the PICs
configuration bits as well as the code. The configuration bits are
one time programmable if I remember correctly and they are not in the
application image. If the configuration bits aren't correct the
oscillator won't even startup.
73's Skip
On Sat, Aug 20, 2022 at 7:24 PM Bradley Andrews via groups.io
<kb9bpf@...> wrote:
Hi Skip, and thanks for the tips.
Yes, I did include the extra SIP resistor network. I also changed the two smaller SIPs to a single SOIC resistor network, included a couple extra bypass caps, and scooted things around slightly for space. And I changed the resonator to an SMT.
I'm attempting to attach a PDF of the schematic and the artwork for perusal. Only when I have confirmed that the circuit boards work will I post the ExpressPCB files. I don’t remember of this group allows attachments or not, but I'll try it.
Regarding programming, when you say "The two steps aren't necessary; you can flash everything in one go if you combine the hex files. I did it that way to test the serial port." Do you mean an overlay of the two? I haven't looked at PIC programming for a long time, and only did a couple easy things when I did do it. Back then I used a serial programmer from MBasic, if I remember correctly, and it used standard DIP sockets. I thought I'd use the Phyton because it I have a PLCC adapter for it, but it's made for the ZIF DIP socket on the Phyton, not regular DIP sockets. I'll have to get out the PIC docs again and study up on programming requirements before I waste a lot of people's time and patience asking questions I should figure out on my own.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Skip Hansen
Sent: Saturday, August 20, 2022 7:45 PM
To: [email protected]
Subject: Re: [xcat] DIY Xcats
On Sat, Aug 20, 2022 at 4:53 PM Bradley Andrews via groups.io
<kb9bpf@...> wrote:
Hi Skip,
Thank you for giving your blessing to those of us who are brave/crazy in this way. I’ve wanted to do this for some time but didn’t want to step on your (or Lee’s) toes.
Would you mind answering a couple questions for me?
1. How did you guys program your PICs? Did you do it in a stand-alone programmer before soldering to the PCB, or did you do it via the RS232 serial port on the Xcat?
Neither. The programming pins are available via a combination of the
accessory cable and the connector normally connected to the Syntor. I
connected the necessary pins to a PIC programmer and programmed the
bootloader. Once the bootloader has been programmed I flashed the
application firmware via the serial port. The two steps aren't
necessary; you can flash everything in one go if you combine the hex
files. I did it that way to test the serial port.
2. Regarding the Xcat firmware, xcat_v033/xcat.hex, if I wanted to program it in my standalone programmer before soldering, would I use ‘Standard/Extended Intel HEX (*.hex, *.mcs)’ whose checksum comes to 001EA2F4, or force it to read in Binary whose checksum is 000CF1CF? I don’t want to do it incorrectly and not find out until the PIC is soldered in place.
You need to program the bootloader first. In addition to the
bootloader itself there are configuration bits which are needed.
FYI, my programmer is a Phyton ChipProg-40.
I don't recall what my programmer was. It wasn't a Microchip product
and the company that made it when out of business long ago. If your
programmer supports the chip it should be fine.
I like ExpressPCB and that’s what I used to lay out my Xcat ‘clone’ boards. If it works, and I expect it will, I’ll have some spares available if anyone is interested in obtaining them (at my cost) and using them to assemble their own. I’ll also be happy to upload the ExpressPCB .sch and .pcb files to the file section of this group, if you give that your blessing, Skip. I’d be willing to provide programmed PICs for those who are interested, as well as the other parts, but only with your blessing, Skip.
That would be EXCELLENT !
Hopefully you've added the pullup resistors that we forgot !
73's Skip WB6YMH
|
Hi Brad, I think you've figured it out. There are lots of lost bits in my memory, but reading the comments in the bootloader code it appears that it expects the application to have put a jump to the start of the application at address 0x02. That's not how I would have done it today, but there may be reasons that I've forgotten. The source for the bootloader is fairly well commented and is available here: --- snip --- ;Simple Intel hex loader/programmer. ; ;Programs a line at a time is into flash and then sends a single character ;response (following receipt of a carrage return). Host software must wait ;for the response before sending the next line. ; ;Loader is entered by holding the serial line in a space state while the ;PIC is turned on (or reset). If the serial line is in a mark state ;immediately after reset the normal application code is run. ; ;Modifications to application program to use loader: ; 1. Start startup at address 2 rather than zero. ; 2. Start application code after the end of loader. ; 3. Ensure only addresses below end of loader programmed by hex file ; are 2 (start vector), 3 and 4 (interrupt vector) ; ;Response after receiving a carrage return character: ;'B' - Begin sending (first line, no prior status to report) ;'P' - Programmed data Ok ;'E' - program Error ;'C' - Checksum error ;'S' - Syntax error (non-hex digit received) ;'I' - last record type Ignored ;'F' - Finished ... jumping to application ;'R' - program address out of range (probably the configuration word), ; record ignored. --- snip --- Good luck! We're all waiting on the edge of our chairs to hear if it works or not! 73's Skip WB6YMH On Mon, Sep 5, 2022 at 1:11 AM Bradley Andrews via groups.io <kb9bpf@...> wrote:
Skip,
I have a question about programming, but first some background and a progress report:
- A couple weeks ago, after I’d gotten my boards, I programmed a PIC with picldr.hex using my Phyton ChipProg-40 and the DIP-to PLCC adapter. When I tried to connect the PC to upload the rest of the firmware through the Xcat PC software, it didn’t work, getting stuck waiting for the download request from the Xcat.
- So, I’ve built a programming adapter and had a go at it again. The programmer says the PIC programs OK and verifies OK. Then I try a read and it comes back all 0000. A re-verify comes back all 0000.
- I did some more reading, pulling down books that I haven’t looked in for 13 years. So it’s looking like the protect bit is set in the config register. I didn’t find - until just now as I’m thinking better (after some rest) - the place in the Phyton to set the device config.
- I found that the picldr.hex file puts 1F76 in location 2007, the config register, which sets the memory protection. I turned it off in the config and changed location 2007 in the program buffer and could read back the (now modified) picldr.hex code I programmed, but when I put the PIC in the Xcat in the Syntor X, and attempted to use the Xcat PC software to upload the v033 firmware, it still wouldn’t go past the stage of waiting for the download request from the Xcat even after power-cycling the radio.
So now my question to you, Skip, is this: What am I doing incorrectly? To quickly summarize what I’ve been doing: flash the picldr, then attempt to use Xcat PC to upload the v033 firmware.
Oh and FYI, the config bits are not OTP: they can be changed if you run a complete erase. So at least I’m not trashing $9 PICs while I learn.
Once I figure out how to correctly get the PICs programmed, I’ll be able to verify the proper function of the PCB, and then I’ll be able to share the fruits of my labors. I think I’m just missing some small but essential piece of the programming puzzle.
Thank for the help,
Brad KB9BPF
From: [email protected] [mailto:[email protected]] On Behalf Of Bradley Andrews via groups.io
Sent: Saturday, August 20, 2022 10:22 PM
To: [email protected]
Subject: Re: [xcat] DIY Xcats
I was writing the other while you were writing this. Sounds like I may have to build a programming adapter access the appropriate pins on the Xcat, like you did.
I need to have a think on it and do some reading so that I don't bother you or the group with my ignorance When I have more intelligent questions I'll come back. Thanks for your willingness to help!
73
Brad KB9BPF
On Saturday, August 20, 2022, 10:06:42 PM CDT, Skip Hansen <skip@...> wrote:
Hi Bradley,
It should be possible to combine the two hex files by just deleting
the end of file line in one and then appending the contents of the
other. On the other hand, just flashing both of them sequentially is
probably way easier than screwing around combining the files. Just
make sure you aren't doing a whole chip erase twice (grin).
The bootrom's hex file should contain the values for the PICs
configuration bits as well as the code. The configuration bits are
one time programmable if I remember correctly and they are not in the
application image. If the configuration bits aren't correct the
oscillator won't even startup.
73's Skip
On Sat, Aug 20, 2022 at 7:24 PM Bradley Andrews via groups.io
<kb9bpf@...> wrote:
Hi Skip, and thanks for the tips.
Yes, I did include the extra SIP resistor network. I also changed the two smaller SIPs to a single SOIC resistor network, included a couple extra bypass caps, and scooted things around slightly for space. And I changed the resonator to an SMT.
I'm attempting to attach a PDF of the schematic and the artwork for perusal. Only when I have confirmed that the circuit boards work will I post the ExpressPCB files. I don’t remember of this group allows attachments or not, but I'll try it.
Regarding programming, when you say "The two steps aren't necessary; you can flash everything in one go if you combine the hex files. I did it that way to test the serial port." Do you mean an overlay of the two? I haven't looked at PIC programming for a long time, and only did a couple easy things when I did do it. Back then I used a serial programmer from MBasic, if I remember correctly, and it used standard DIP sockets. I thought I'd use the Phyton because it I have a PLCC adapter for it, but it's made for the ZIF DIP socket on the Phyton, not regular DIP sockets. I'll have to get out the PIC docs again and study up on programming requirements before I waste a lot of people's time and patience asking questions I should figure out on my own.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Skip Hansen
Sent: Saturday, August 20, 2022 7:45 PM
To: [email protected]
Subject: Re: [xcat] DIY Xcats
On Sat, Aug 20, 2022 at 4:53 PM Bradley Andrews via groups.io
<kb9bpf@...> wrote:
Hi Skip,
Thank you for giving your blessing to those of us who are brave/crazy in this way. I’ve wanted to do this for some time but didn’t want to step on your (or Lee’s) toes.
Would you mind answering a couple questions for me?
1. How did you guys program your PICs? Did you do it in a stand-alone programmer before soldering to the PCB, or did you do it via the RS232 serial port on the Xcat?
Neither. The programming pins are available via a combination of the
accessory cable and the connector normally connected to the Syntor. I
connected the necessary pins to a PIC programmer and programmed the
bootloader. Once the bootloader has been programmed I flashed the
application firmware via the serial port. The two steps aren't
necessary; you can flash everything in one go if you combine the hex
files. I did it that way to test the serial port.
2. Regarding the Xcat firmware, xcat_v033/xcat.hex, if I wanted to program it in my standalone programmer before soldering, would I use ‘Standard/Extended Intel HEX (*.hex, *.mcs)’ whose checksum comes to 001EA2F4, or force it to read in Binary whose checksum is 000CF1CF? I don’t want to do it incorrectly and not find out until the PIC is soldered in place.
You need to program the bootloader first. In addition to the
bootloader itself there are configuration bits which are needed.
FYI, my programmer is a Phyton ChipProg-40.
I don't recall what my programmer was. It wasn't a Microchip product
and the company that made it when out of business long ago. If your
programmer supports the chip it should be fine.
I like ExpressPCB and that’s what I used to lay out my Xcat ‘clone’ boards. If it works, and I expect it will, I’ll have some spares available if anyone is interested in obtaining them (at my cost) and using them to assemble their own. I’ll also be happy to upload the ExpressPCB .sch and .pcb files to the file section of this group, if you give that your blessing, Skip. I’d be willing to provide programmed PICs for those who are interested, as well as the other parts, but only with your blessing, Skip.
That would be EXCELLENT !
Hopefully you've added the pullup resistors that we forgot !
73's Skip WB6YMH
|
Skip, I have a question about programming, but first some background and a progress report: -????????? A couple weeks ago, after I’d gotten my boards, I programmed a PIC with picldr.hex using my Phyton ChipProg-40 and the DIP-to PLCC adapter. When I tried to connect the PC to upload the rest of the firmware through the Xcat PC software, it didn’t work, getting stuck waiting for the download request from the Xcat. -????????? So, I’ve built a programming adapter and had a go at it again. The programmer says the PIC programs OK and verifies OK. Then I try a read and it comes back all 0000. A re-verify comes back all 0000. -????????? I did some more reading, pulling down books that I haven’t looked in for 13 years. So it’s looking like the protect bit is set in the config register. I didn’t find - until just now as I’m thinking better (after some rest) - the place in the Phyton to set the device config. -????????? I found that the picldr.hex file puts 1F76 in location 2007, the config register, which sets the memory protection. I turned it off in the config and changed location 2007 in the program buffer and could read back the (now modified) picldr.hex code I programmed, but when I put the PIC in the Xcat in the Syntor X, and attempted to use the Xcat PC software to upload the v033 firmware, it still wouldn’t go past the stage of waiting for the download request from the Xcat even after power-cycling the radio. ? So now my question to you, Skip, is this: What am I doing incorrectly? To quickly summarize what I’ve been doing: flash the picldr, then attempt to use Xcat PC to upload the v033 firmware. ? Oh and FYI, the config bits are not OTP: they can be changed if you run a complete erase. So at least I’m not trashing $9 PICs while I learn. ? Once I figure out how to correctly get the PICs programmed, I’ll be able to verify the proper function of the PCB, and then I’ll be able to share the fruits of my labors. I think I’m just missing some small but essential piece of the programming puzzle. ? Thank for the help, Brad KB9BPF ?
toggle quoted message
Show quoted text
From: [email protected] [mailto:[email protected]] On Behalf Of Bradley Andrews via groups.io
Sent: Saturday, August 20, 2022 10:22 PM
To: [email protected]
Subject: Re: [xcat] DIY Xcats ? I was writing the other while you were writing this. Sounds like I may have to build a programming adapter access the appropriate pins on the Xcat, like you did.
I need to have a think on it and do some reading so that I don't bother you or the group with my ignorance When I have more intelligent questions I'll come back. Thanks for your willingness to help!
73
Brad KB9BPF On Saturday, August 20, 2022, 10:06:42 PM CDT, Skip Hansen <skip@...> wrote: Hi Bradley,
It should be possible to combine the two hex files by just deleting
the end of file line in one and then appending the contents of the
other.? On the other hand, just flashing both of them sequentially is
probably way easier than screwing around combining the files.? Just
make sure you aren't doing a whole chip erase twice (grin).
The bootrom's hex file should contain the values for the PICs
configuration bits as well as the code.? The configuration bits are
one time programmable if I remember correctly and they are not in the
application image.? If the configuration bits aren't correct the
oscillator won't even startup.
73's Skip
On Sat, Aug 20, 2022 at 7:24 PM Bradley Andrews via groups.io
<kb9bpf=[email protected]> wrote:
>
> Hi Skip, and thanks for the tips.
>
> Yes, I did include the extra SIP resistor network. I also changed the two smaller SIPs to a single SOIC resistor network, included a couple extra bypass caps, and scooted things around slightly for space. And I changed the resonator to an SMT.
>
> I'm attempting to attach a PDF of the schematic and the artwork for perusal. Only when I have confirmed that the circuit boards work will I post the ExpressPCB files. I don’t remember of this group allows attachments or not, but I'll try it.
>
> Regarding programming, when you say "The two steps aren't necessary; you can flash everything in one go if you combine the hex files.? I did it that way to test the serial port." Do you mean an overlay of the two? I haven't looked at PIC programming for a long time, and only did a couple easy things when I did do it. Back then I used a serial programmer from MBasic, if I remember correctly, and it used standard DIP sockets. I thought I'd use the Phyton because it I have a PLCC adapter for it, but it's made for the ZIF DIP socket on the Phyton, not regular DIP sockets. I'll have to get out the PIC docs again and study up on programming requirements before I waste a lot of people's time and patience asking questions I should figure out on my own.
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Skip Hansen
> Sent: Saturday, August 20, 2022 7:45 PM
> To: [email protected]
> Subject: Re: [xcat] DIY Xcats
>
> On Sat, Aug 20, 2022 at 4:53 PM Bradley Andrews via groups.io
> <kb9bpf=[email protected]> wrote:
> >
> > Hi Skip,
> >
> > Thank you for giving your blessing to those of us who are brave/crazy in this way. I’ve wanted to do this for some time but didn’t want to step on your (or Lee’s) toes.
> >
> >
> >
> > Would you mind answering a couple questions for me?
> >
> > 1.? ? ? How did you guys program your PICs? Did you do it in a stand-alone programmer before soldering to the PCB, or did you do it via the RS232 serial port on the Xcat?
>
> Neither.? The programming pins are available via a combination of the
> accessory cable and the connector normally connected to the Syntor.? I
> connected the necessary pins to a PIC programmer and programmed the
> bootloader.? Once the bootloader has been programmed I flashed the
> application firmware via the serial port.? The two steps aren't
> necessary; you can flash everything in one go if you combine the hex
> files.? I did it that way to test the serial port.
>
> >
> > 2.? ? ? Regarding the Xcat firmware, xcat_v033/xcat.hex, if I wanted to program it in my standalone programmer before soldering, would I use ‘Standard/Extended Intel HEX (*.hex, *.mcs)’ whose checksum comes to 001EA2F4, or force it to read in Binary whose checksum is 000CF1CF? I don’t want to do it incorrectly and not find out until the PIC is soldered in place.
>
> You need to program the bootloader first.? In addition to the
> bootloader itself there are configuration bits which are needed.
>
> >
> > FYI, my programmer is a Phyton ChipProg-40.
>
> I don't recall what my programmer was.? It wasn't a Microchip product
> and the company that made it when out of business long ago.? If your
> programmer supports the chip it should be fine.
>
> >
> >
> >
> > I like ExpressPCB and that’s what I used to lay out my Xcat ‘clone’ boards. If it works, and I expect it will, I’ll have some spares available if anyone is interested in obtaining them (at my cost) and using them to assemble their own. I’ll also be happy to upload the ExpressPCB .sch and .pcb files to the file section of this group, if you give that your blessing, Skip. I’d be willing to provide programmed PICs for those who are interested, as well as the other parts, but only with your blessing, Skip.
>
> That would be EXCELLENT !
>
> Hopefully you've added the pullup resistors that we forgot !
>
> 73's Skip WB6YMH
>
>
>
>
>
>
>
>
>
|
Re: Code plug Rx and Tx frequencies cracked
Yes Mike, please!
How was the file generated, hex editing or RSS?? If RSS what version?
I don't have any examples of more than 64 modes and I don't think the RSS I'm using supports it.
73's Skip WB6YMH
|
Re: Code plug Rx and Tx frequencies cracked
Skip, I have some 128 mode Loband and UHF .RDT files if they would be any help to you.
tnx
Mike / K5JR
Alpharetta GA
toggle quoted message
Show quoted text
On Aug 31, 2022, at 9:28 PM, Skip Hansen <skip@...> wrote: ?Don't go to a lot of trouble. I can generated .RDT files as well. Just if you had some lying around I'll parse them just to throw some variety at my dumper. 73's Skip WB6YMH On Wed, Aug 31, 2022 at 6:08 PM swguest via groups.io <swguest@...> wrote:
@ Skip,
Are you still in need of .rdt files? I dont have anything built that's useful. I can build you whatever you need modes, band, PLs/MPLs etc.
Not all .RDTs are interchangable across different versions of RSS. I have V6.0.0 and I think I have the HAM version of V6 also.
I ran a "print/report" and was looking it over. There is a lot of irellevant info in it.
It you need one you made "parsed out" to the essentials I can import it to Excel, parse it, and post it back. Let me work on it a bit and I should be able to add freq to bytes to the parsed data as well.
|
Re: Code plug Rx and Tx frequencies cracked
I call bull. :-)
Since there is no such thing as 'inverted' DPL/DCS/CDCSS/Etc there is no compatibility issue aside from knowing the conversion between inverted vs normal codes.
Motorola probably left it out (if they did) since it is an illusion.
Yes, some receivers use opposite side injection, but that is true even WITHIN manufacturers, and even within the same models. When opposite side injection is used, the bit pattern is inverted and corresponds to a different code.
Again, all you need to know is the conversion.
For those who do not, here it is:
023 047
025 244
026 464
031 627
032 051
036 172
043 445
047 023
051 032
053 452
054 413
065 271
071 306
072 245
073 506
074 174
114 712
115 152
116 754
122 225
125 365
131 364
132 546
134 223
143 412
145 274
152 115
155 731
156 265
162 503
165 251
172 036
174 074
205 263
212 356
223 134
225 122
226 411
243 351
244 025
245 072
246 523
251 165
252 462
255 446
261 732
263 205
265 156
266 454
271 065
274 145
306 071
311 664
315 423
325 526
331 465
332 455
343 532
346 612
351 243
356 212
364 131
365 125
371 734
411 226
412 143
413 054
423 315
431 723
432 516
445 043
446 255
452 053
454 266
455 332
462 252
464 026
465 331
466 662
503 162
506 073
516 432
523 246
526 325
532 343
546 132
565 703
606 631
612 346
624 632
627 031
631 606
632 624
654 743
662 466
664 311
703 565
712 114
723 431
731 155
732 261
734 371
743 654
754 116
There. I just solved the compatibility problem. :-)
Joe M.
toggle quoted message
Show quoted text
On 9/1/2022 2:50 PM, Skip Hansen wrote: When I was refreshing my (lack of) memory on DCS one thing that I
noticed was the inverting was really only of concern when talking from
one manufacturer to another. Maybe big M left out inversion
intentionally to screw compatibility.
As Dennis and I know DCS compatibility can definitely be an issue!
73's Skip WB6YMH
On Thu, Sep 1, 2022 at 9:26 AM Dennis Boone <drb@...> wrote:
> Some of the extra info could be normal/inverted.
> But you can still program inverted codes in most RSS.
RSS doesn't seem to have an option for inverting, so you have to do it
by entering the inverse code instead. Therefore I don't think they
expended a bit on it in the code plug. That's interesting since the X
does have a code plug bit for invert.
De
|
Re: Code plug Rx and Tx frequencies cracked
When I was refreshing my (lack of) memory on DCS one thing that I
noticed was the inverting was really only of concern when talking from
one manufacturer to another. Maybe big M left out inversion
intentionally to screw compatibility.
As Dennis and I know DCS compatibility can definitely be an issue!
73's Skip WB6YMH
toggle quoted message
Show quoted text
On Thu, Sep 1, 2022 at 9:26 AM Dennis Boone <drb@...> wrote:
> Some of the extra info could be normal/inverted.
> But you can still program inverted codes in most RSS.
RSS doesn't seem to have an option for inverting, so you have to do it
by entering the inverse code instead. Therefore I don't think they
expended a bit on it in the code plug. That's interesting since the X
does have a code plug bit for invert.
De
|
Re: Code plug Rx and Tx frequencies cracked
Some of the extra info could be normal/inverted. > But you can still program inverted codes in most RSS. RSS doesn't seem to have an option for inverting, so you have to do it by entering the inverse code instead. Therefore I don't think they expended a bit on it in the code plug. That's interesting since the X does have a code plug bit for invert. De
|
Re: Code plug Rx and Tx frequencies cracked
Some of the extra info could be normal/inverted.
Someone decided it would sound good to double the codes with 'inverted' codes, but in reality it's all marketing, as every inverted code corresponds to a normal code. (for example, inverted 023 is normal 047)
But you can still program inverted codes in most RSS.
Joe M.
toggle quoted message
Show quoted text
On 9/1/2022 3:11 AM, Dennis Boone wrote: I spent most of today's X9000 hacking staring at DPL. I think I've
found part of the pattern. 'Scusing the crappy formatting, here are
several DPL codes, their bit patterns, the two byte hex value generated
by RSS, and the bit pattern for that.
dpl 000000023 dpls 000010011 rss f864 rsss 1111100001100100
dpl 000000025 dpls 000010101 rss fc54 rsss 1111110001010100
dpl 000000026 dpls 000010110 rss f434 rsss 1111010000110100
dpl 000000031 dpls 000011001 rss fc4c rsss 1111110001001100
dpl 000000116 dpls 001001110 rss f039 rsss 1111000000111001
dpl 000000125 dpls 001010101 rss f855 rsss 1111100001010101
dpl 000000131 dpls 001011001 rss f84d rsss 1111100001001101
dpl 000000244 dpls 010100100 rss e912 rsss 1110100100010010
dpl 000000245 dpls 010100101 rss fd52 rsss 1111110101010010
dpl 000000251 dpls 010101001 rss fd4a rsss 1111110101001010
dpl 000000411 dpls 100001001 rss ecc8 rsss 1110110011001000
dpl 000000412 dpls 100001010 rss e4a8 rsss 1110010010101000
dpl 000000413 dpls 100001011 rss f0e8 rsss 1111000011101000
dpl 000000734 dpls 111011100 rss e99d rsss 1110100110011101
dpl 000000743 dpls 111100011 rss f5e3 rsss 1111010111100011
dpl 000000754 dpls 111101100 rss fd9b rsss 1111110110011011
The full bit pattern sent by the transmitter, read left to right,
consists of 11 Golay parity bits (p10-p0), then the '100' (4) that's
part of every DPL code (c2-c0), then the nine bits that represent the
part of the DPL code that is typically listed in the table (d8-d0). But
all of this is sent LSB (d0) first, i.e. for the code '023', the first
bits sent are '110010000' -- the reverse of the dpls column entry shown
above for 023. Mike has some nice diagrams of the bit layout on the DPL
page at onfreq. This is the full word for 023:
11101100011-100-000/010/011
Number the bits of rsss from b0 at the low order end to b15 at the high
end. If you compare d0-d6 (i.e. reversed) of dpls for each code above
to b6-b0 (i.e. not reversed) of rsss, you'll see they match. Then d7-d8
of dpls to b8-b7 of rsss again match.
That leaves b15-b9 of rsss to explain. Skip thinks there are a couple
of flags in there. In the X, the top three Golay parity bits are part
of the code plug, so something like that could be going on here.
De
|
