When programming some codeplugs in Saber RSS (07.01.00), I get a Serial I/O Bus error.
I'm trying to put in some new channels, and it's consistently giving me a Serial I/O error. I can read fine, but when I go to program, it reads in the old channels, and then throws the Serial I/O error. I can pull up old, saved codeplugs and program those back in without a problem. It's not an 'intermittent' problem, it happens always with the new codeplug I'm writing, and never with the old codeplugs. Radio's a Saber 3, secure; I'm writing four zones, maybe about 30 channels total, a few different PLs. (No weird features, just zone and chanel operation with names, mode-slaved scan.)
How do I go about fixing, or even diagnosing, this?
Certain Codeplugs Give Serial I/O Error (Saber RSS)
Moderator: Queue Moderator
Have you changed the model type in this new codeplug?
You state you are programming 30 channels into 4 zones, is that the actual amount that is programmed in the radio as well?
I/O errors usually come from DOS errors, not from programming errors.
Blank/unprogrammed channels will still have data so they can be programmed and allow the radio to function, unlike the Systems Sabers, that will indicate the error and also 'destroy' any personality NOT associated with a mode, scan list or channel.
Check you cables, computer end as well as R.I.B and programming.
What speed is the computer running at as well?
Sompe allow use of DOS shells to program certain radios, but allways, best bet is to make sure you are not in a DOS shell and have no conflicts.
But also, from your admission, you can program the old CP back into the radio, which tells me your 'new' CP data is flawed in some manner, I would check that over closely and examine every aspect of it as well, then move on to other areas.
You can also get I/O errors if you allow the radio to transmit close to the R.I.B during a write or read cycle, and this should not be alloweed to occur as the RF can introduce errors and hose the CP data you are attempting to write.
Also, if your radio is an older version, say an 'AN' version and you are attempting to force a later 'CN' version in, you can also get this error as well.
As always, check for charged batteries in the R.I.B as well as the radio, and that all contacts are clean and free of oxide buildup and dirt, and that you have a solid connection as well.
Something's not set up properly within your codeplug since dumping the old one back into the radio produces no errors, this appears to be a codeplug-only problem.
I wish you luck in clearing it up!
You state you are programming 30 channels into 4 zones, is that the actual amount that is programmed in the radio as well?
I/O errors usually come from DOS errors, not from programming errors.
Blank/unprogrammed channels will still have data so they can be programmed and allow the radio to function, unlike the Systems Sabers, that will indicate the error and also 'destroy' any personality NOT associated with a mode, scan list or channel.
Check you cables, computer end as well as R.I.B and programming.
What speed is the computer running at as well?
Sompe allow use of DOS shells to program certain radios, but allways, best bet is to make sure you are not in a DOS shell and have no conflicts.
But also, from your admission, you can program the old CP back into the radio, which tells me your 'new' CP data is flawed in some manner, I would check that over closely and examine every aspect of it as well, then move on to other areas.
You can also get I/O errors if you allow the radio to transmit close to the R.I.B during a write or read cycle, and this should not be alloweed to occur as the RF can introduce errors and hose the CP data you are attempting to write.
Also, if your radio is an older version, say an 'AN' version and you are attempting to force a later 'CN' version in, you can also get this error as well.
As always, check for charged batteries in the R.I.B as well as the radio, and that all contacts are clean and free of oxide buildup and dirt, and that you have a solid connection as well.
Something's not set up properly within your codeplug since dumping the old one back into the radio produces no errors, this appears to be a codeplug-only problem.
I wish you luck in clearing it up!
-
fogster
- Posts: 386
- Joined: Sun Nov 06, 2005 10:38 am
- What radios do you own?: XTS2500/5000, XPR7550/5550
Well, sort of. It's an H43, but I program it as an H33. (This isn't the same radio I was taking way out of band in previous threads... It's got the high-split VHF, I just want 146.52 and 162.4 in the same radio.)AEC wrote:Have you changed the model type in this new codeplug?
Well, nothing gets programmed since it fails immediately after reading in the old codeplug. (And it was a total of 30 channels, across 4 zones, not 30 channels each in 4 zones. Lest anyone think I've got some serious issues with doing the impossible.)You state you are programming 30 channels into 4 zones, is that the actual amount that is programmed in the radio as well?
The battery in my RIB was starting to get low, so I'm running it off of 12v external now. This makes no difference, though. All cables are intact.Check you cables, computer end as well as R.I.B and programming.
233 MHz, IIRC. I've had no trouble in the past, and read of others using much faster computers with Saber RSS, so I don't think that's the issue. Also, this is 'real' DOS, no Windows.What speed is the computer running at as well?
I put in a very basic codeplug, and it worked. I filled up the first zone, and put a few channels in the second, and wrote that out. It programmed fine, but just gave me a "ERR 1 05," which seems to be a failure of both the internal and external EEPROM? I was able to put a known-good codeplug back in. I just can't figure out why using a second zone seems to always cause problems.But also, from your admission, you can program the old CP back into the radio, which tells me your 'new' CP data is flawed in some manner, I would check that over closely and examine every aspect of it as well, then move on to other areas.
Nope, I've never transmitted hooked up to the RIB.You can also get I/O errors if you allow the radio to transmit close to the R.I.B during a write or read cycle
It's a -CN.Also, if your radio is an older version, say an 'AN' version and you are attempting to force a later 'CN' version in, you can also get this error as well.
It just seems really weird to me that attempting to write a codeplug using zones would generate an immediate serial bus error. I could see it complaining about some invalid configuration, or the radio showing an error code, but a serial bus error?
I would have to review my RSS manual and see what that code is, but it's probably a checksum error at the least, or possibly a defective EEPROM that is intermittent and could be related to heat buildup that causes it to fail after a brief time.
You have the correct band split, so that should not even be a consideration or problem to work through, you have a front shield problem then, and it deals specifically with the memory of that board.
Is the memory board a 'genuine' 2K memory board?
If it isn't, then you selected the wrong options in F4 and selected the 'omit memory-2K memory' option, which can cause errors due to codeplug data mismatch.
The real 2K memory MUST have the F4 option selected, or you will have write errors as I have had the RSS attempt to program optionns into that memory board than can actually be programmed or used, which hosed the entire codeplug requiring an entire rewrite.
How many 'chips' does your memory board have?
Four or five?
Four indicates an actual 2K memory option, and five indicates the 8K option which will allow 120 channel operation.
The fifth being a tone generator for DTMF on the 8K board.
The 2K board is not capable of DTMF operation as you are probably well aware.
Check the LCD interconnect to the main board, if it's not seated fully, it may show errors as the connector is not making good electrical contact.
A display showing ERR 1/05 is not normal and if this error keeps showing, it's probably due to a defective EEPROM on the display/memory board if a codeplug rewrite can't write out this error.
Without seeing the actual items, it's difficult to remotely decipher the cause of a problem, especially if that problem is not 'routine' in a list of continued failures that show up often.
You have the correct band split, so that should not even be a consideration or problem to work through, you have a front shield problem then, and it deals specifically with the memory of that board.
Is the memory board a 'genuine' 2K memory board?
If it isn't, then you selected the wrong options in F4 and selected the 'omit memory-2K memory' option, which can cause errors due to codeplug data mismatch.
The real 2K memory MUST have the F4 option selected, or you will have write errors as I have had the RSS attempt to program optionns into that memory board than can actually be programmed or used, which hosed the entire codeplug requiring an entire rewrite.
How many 'chips' does your memory board have?
Four or five?
Four indicates an actual 2K memory option, and five indicates the 8K option which will allow 120 channel operation.
The fifth being a tone generator for DTMF on the 8K board.
The 2K board is not capable of DTMF operation as you are probably well aware.
Check the LCD interconnect to the main board, if it's not seated fully, it may show errors as the connector is not making good electrical contact.
A display showing ERR 1/05 is not normal and if this error keeps showing, it's probably due to a defective EEPROM on the display/memory board if a codeplug rewrite can't write out this error.
Without seeing the actual items, it's difficult to remotely decipher the cause of a problem, especially if that problem is not 'routine' in a list of continued failures that show up often.
-
fogster
- Posts: 386
- Joined: Sun Nov 06, 2005 10:38 am
- What radios do you own?: XTS2500/5000, XPR7550/5550
http://www.batlabs.com/sabreror.html says it's an error in the COPE, and it's 01+04, which are, respectively, internal and external EEPROM checksum failures. I was able to reprogram the old codeplug with no problems, so I think it was just a bad codeplug...?AEC wrote:I would have to review my RSS manual and see what that code is, but it's probably a checksum error at the least
I'm not sure it's heat-related. It seems to only happen when I program a 'bigger' codeplug.or possibly a defective EEPROM that is intermittent and could be related to heat buildup that causes it to fail after a brief time.
I have 5 chips, which I guess makes it an 8K board. (Neither Batlabs nor Repeater Builder seems to have any pictures. They'd be quite handy for this. But there are five chips.) I haven't selected the 2K option. (And my understanding is that it's irreplacable, short of major hacks involving corrupting the codeplug?)Is the memory board a 'genuine' 2K memory board?
I did a bit of experimentation... In the channel programming screen, I just repeatedly hit "Insert Channel," generating about 20 channels with no name. (Two zones.) The radio took it fine. I was also able to add names ("ASDF" and the like) without problem.
However, when I put in 12 'real' channels, with different RX and TX frequencies, and some with PLs, RSS barfs up the Serial Bus error again.
So it's not strictly based on zones, but seems to be more a factor of how 'big' the codeplug is.[/url]
COPE: Control of Peripheral Electronics, as in the front display/memory.
Which can be a problem within the EEPROM that stores codeplug information.
You may have 'hit the limit' as it were when it comes to allocated space, and anything larger causes corruption, as a defective EEPROM would cause.
I would swap the display/memory with another, I bet the problem goes away.
Since the EEPROM works with rows and columns, and each of these contain 'cells' and when the microprocessor 'strobes' or places a 'call' to these areas, they become active, whereas the defective cells are no longer able to respond to these calls, they cause the RSS to halt due to the error.
In short, the EEPROM is 'partially' dead, and only a fraction of the alloted space is able to be used, the remainder is no longer functioning.
Which can be a problem within the EEPROM that stores codeplug information.
You may have 'hit the limit' as it were when it comes to allocated space, and anything larger causes corruption, as a defective EEPROM would cause.
I would swap the display/memory with another, I bet the problem goes away.
Since the EEPROM works with rows and columns, and each of these contain 'cells' and when the microprocessor 'strobes' or places a 'call' to these areas, they become active, whereas the defective cells are no longer able to respond to these calls, they cause the RSS to halt due to the error.
In short, the EEPROM is 'partially' dead, and only a fraction of the alloted space is able to be used, the remainder is no longer functioning.