Hi All, I have a small project that uses a PIC 16F1829, running at 16 MHz, and a FTDI FT230XS USB to Serial interface chip. The project works OK in most respects, but I get intermittent serial data errors when running at 9600 Baud. If I drop to 4800 Baud, it seems to be stable. Although this is not a disaster, it would be great to stabilise it at 9600 B. I use the HserSend and HserReceive commands to send and receive data, and the port has Blocking switched on. Does anyone have a suggestion that could fix the error problem? Thanks! Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
;-----Configuration#chip 16F1829, 16#option explicit;-----Constants'Setup Serial Port#define SerInPort PORTB.5#define SerOutPort PORTB.7' Define the USART port#define USART_BAUD_RATE 4800#define USART_BLOCKING#define USART_DELAY off;-----DefineHardwaresettings'Set pin directionsDirSerOutPortOutDirSerInPortIn'Mount bump portsDIRPORTC.7Out'WestDIRPORTC.6Out'SouthDIRPORTC.5Out'NorthDIRPORTC.4Out'East'Servo portsDIRPORTC.2OutDIRPORTC.3Out'Focus motor portsDIRPORTC.0OutDIRPORTC.1Out'Encoder portsDIRPORTA.0In'A-D port for temperatureDIRPORTA.4InDIRPORTA.5InDimTEMPasByteDimShiftasWordDimTiltasWordDimTilt_NSasWordDimTilt_EWasWordDimSData(8)asWordDimCntasWordDimDataCountasWordDimCountStoreasByteDimEncoderasWordDimTemperatureasWordDimFocusasWordDimOutvarasStringDimversionasWordDimTempvar1asWordDimTempvar2asWordTilt_NS=1500'set AO servos to centreTilt_EW=1500EPRead0,Encoder'read current stored focus encoder count at startupEncoder=1500CallReadTemperature'EPRead 10, Temperature 'readstoredtemperaturevalueTemp=HSerReceive'handshake at start-upHSerSendTemp'send versionversion=100HSerPrintversion'HSerPrint EncoderSetPORTC.0Off'switch off output portsSetPORTC.1OffSetPORTC.2OffSetPORTC.5OffSetPORTC.6OffSetPORTC.7Off
~~~
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
;Program compiled by Great Cow BASIC (0.99.01 2022-01-27 (Windows 64 bit) : Build 1073) for Microchip MPASM
;Need help? See the GCBASIC forums at http://sourceforge.net/projects/gcbasic/forums,
;check the documentation or email w_cholmondeley at users dot sourceforge dot net.
;**************
;Set up the assembler options (Chip type, clock source, other bits and pieces)
LIST p=16F1829, r=DEC
Thank you. Your compiler and tool chain is 12 months old. We have changed the USART in the interim period.
However, this may been as simple as BPS support in the chip. Check the datasheet for the problematic BPS at the Mhz you have selected. Changing the Mhz may resolve. The datasheet will detail the BPS errors at specific Mhz.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I tried the latest compiler, but the errors persist. I then had a look at the 16F1829 data sheet and it shows an error of 0.16% at 16MHz and 9600 Baud, so that looks good.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the new compiler add #DEFINE ISSUE_CHECK_USART_BAUD_RATE_WARNING this will show the calculated BPS. See the Help for this new constant. If the value is close to 4800 or 9600 then you make want to look at the TTT/USB interface.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you could look at InitUsart - there registers are obvious and just check the register ( for BPS ) calculate to 9615 BPS. You will find this in the ASM file produced by the compiler for you project.
The new constant is a reverse calculation of the values used to set the BPS. But, there is nothing better than checking the register value being used.
And, do check the Errata. Anything related to the USART ?
Last edit: Anobium 2023-01-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps describe the problem a little better than "intermittent serial data errors when running at 9600 Baud".
Is the problem when sending or receiving (or both)?
What are the symptoms ? Missed characters, wrong characters or something else.
What program or terminal app receives the serial data from the PIC?
You mentioned you are using a FTDI 230XS Chip. Shall we assume this is a commercial module with genuine FTDI chip on it and not one of the many fake/ counterfeits out there?
The FTDI 230X operates at 3.3V I/O levels. Are you also operating the PIC at 3.3V ?
Have you tried adding a delay as a test with < #define USART_DELAY 1 ms >
I have used 16F1829 at baud rates from 9600 up to to 115200 for years without any problems;
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi William, OK - I'll try to be more precise. Basically, the problem consists of incorrect characters in the data received by the hardware. The software sends 7 byte character strings to the board, which start with a 'command' letter (typically 'G' or 'M') followed by 6 digits. The digital part is a value that the board uses to determine how much a motor will move in response to the command. What happens is that I will see a 'G' or 'M' returned when everything is good, but every few commands, I will get back one of the digits, rather than the command letter. This causes the motor to not respond and often causes a 'time out' on the next command string.
The software in use is well-tried over several years and I can get similar errors when using the GCB terminal to send the strings.
The FT230 is on the board and not in a serial module, so I know that it is a good chip.
The PIC is running at 5 volts.
I've just tried adding the 1 ms delay, but no apparent change is seen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have found that the 1 ms delay does nothing at all at 9600. Nothing. To get any delay you must increase it to 2 ms . So try #Define USART_DELAY 2 ms. This will add about 1 ms between bytes sent by the PIC to wherever it is going. This can allow some devices to receive data when more than a few bytes are sent back to back.
It is highly unlikely that the problem is related to inaccurate baud rate on the PIC side. I have an 16F1829 on a breadboard here and with a scope have measured the output baud rate to be 9617. More than good enough for even demanding applications. So unless you have measured the baud rate and found it to be inaccurate I will call that good. The issue lies elsewhere.
Basically, the problem consists of incorrect characters in the data received by the hardware.
What hardware are you referring to ? What is sending the data ?
The software sends 7 byte character strings to the board, which start with a 'command' letter (typically 'G' or 'M') followed by 6 digits.
What software ? Is this your GCB code or some application ?
What board?
What I am trying to get to here is exactly what you are trying to do, where the PIC comes into play, and why you suspect that the PIC or GCB is the root cause of the problem.
Post your complete BASIC code so that I can attempt to see what you are doing. Also post a schematic that shows how the PIC is interconnected with other devices.
In the mean time do try #Define USART_DELAY 2ms and see what happens.
If the issue is related to the PIC receiving data, understand that the PIC has only a 2 byte buffer and each byte/character must be received and then moved quickly into a variable or into an array before the next byte can be received.
William
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If the incoming data is not being appropriately handled then a ring buffer using an interrupt will resolve. But, we need a fuller picture and the complete code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK Gents - thanks for the input, but I've now traced the problem to a functional issue in the code. The program uses timer 0 interrupts to generate a steady pulse train for the hardware and it seems that the interrupts can corrupt the serial data when they occur at the wrong moment. Unfortunately, I've not yet found a way to prevent this from happening - any ideas will be very welcome!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have examined your code and tried to make sense of it as best I can. There are some significant issues that need to be addressed.
1). The interrupt service routine is way too large. Nothing else can happen while the ISR code is executing. Common practice is to make the ISR as short as possible, set some "flags", and get out.
2). If the HserReceive code is executing and an interrupt is triggered during that time there could be data corruption/ missing data.
3). The interrupt routine is generating a 61 Hz Frame rate for the servos. This should be 50 Hz for analog servos but will be OK for digital servos. You have not said what kind you have.
4). The code seems bloated with the unnecessary use of VAL,CHR to get the data into the proper format.
5). There are unused variables cluttering up the code
6). The general code structure is not very good and is quite inefficient.
7). The variable names are not particularly descriptive. For Example: "cnt"
Nomally "cnt" would be descriptive of a counter of sorts. While you may know the purpose/ function of ''cnt" others like myself looking at the code have to attempt to decipher what it actually does by examining nearly every line of code to make any sense of it.
8). You have never clearly described the project in full and provided any relevant specifications. We do not know what "software" you are using, what the "board" is that you have referred to or even what the actual device is that you are hoping to control. All I know is that it appears to use 2 or three servos, possibly for tilting or panning something and to control the "focus" of something or another (maybe a camera?) We do not know what the "bump" stuff does or is supposed to do. There are no comments in the code to tell us.
My suggestion is to start over with a complete re-write one section at a time. Personally I would not use a timer/interrupt to generate the servo pulses. I would instead use the chips PWM modules and most likely a more modern chip than the 16F1829. Something like a K42 series or even better a Q series. These are all cheap, but admittedly may be hard to source at this time ( global chip shortage). But if you want a recommendation just ask. If you are married to the 16F1829 then so be it. We can try.
We can provide specific help only if we have the specifics of your project ( No crystal balls here and I do not like to guess) ... Otherwise the help will be general and probably not sufficient you get you up and running with such a complex project.
William
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes that is a good choice and probably a few cents cheaper than the 18F16Q41 that I was going to suggest (my 20 pin favorite). Either of these would be a great alternative. And since these have PPS ( Peripheral Pin Select) the serial I/O and PWM signals can be mapped to almost any pin.
Last edit: William Roth 2023-01-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I may have found the main culprit that is responsible for the data corruption.
On line 102 the code is telling the PIC to sending a data byte while your software/terminal is still sending the 7 byte string. So the next HserReceive after the HSersend is too late to get the next byte. A byte is missed.
Comment out this line and see if this solves the data corruption issue. It did for me.
102....HSerSendTemp'Echosentcommand
Alternatively you could have the software that is sending the data to add a 1 or 2 ms transmit delay between each byte.
This may quickly solve you main issue or at least part of it. I
William
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All, I have a small project that uses a PIC 16F1829, running at 16 MHz, and a FTDI FT230XS USB to Serial interface chip. The project works OK in most respects, but I get intermittent serial data errors when running at 9600 Baud. If I drop to 4800 Baud, it seems to be stable. Although this is not a disaster, it would be great to stabilise it at 9600 B. I use the HserSend and HserReceive commands to send and receive data, and the port has Blocking switched on. Does anyone have a suggestion that could fix the error problem? Thanks! Terry
Can you attach your program to a post? need to see the code.
Also post the top four lines of the ASM file.
Thanks
Hi Anobium, Here are the first lines of the ASM and the source. Thanks!
Terry
~~~
I need the top lines of the asm.
Here are a few dozen lines:
~~~
;Program compiled by Great Cow BASIC (0.99.01 2022-01-27 (Windows 64 bit) : Build 1073) for Microchip MPASM
;Need help? See the GCBASIC forums at http://sourceforge.net/projects/gcbasic/forums,
;check the documentation or email w_cholmondeley at users dot sourceforge dot net.
;**************
;Set up the assembler options (Chip type, clock source, other bits and pieces)
LIST p=16F1829, r=DEC
include <p16f1829.inc></p16f1829.inc>
__CONFIG _CONFIG1, _FCMEN_ON & _CLKOUTEN_OFF & _CPD_OFF & _CP_OFF & _MCLRE_OFF & _WDTE_OFF & _FOSC_INTOSC
__CONFIG _CONFIG2, _LVP_OFF & _PLLEN_OFF & _WRT_OFF
;**************
;Set aside memory locations for variables
ADN_PORT EQU 32
ADREADPORT EQU 33
CHR EQU 9159
CNT EQU 34
CNT_H EQU 35
COMPORT EQU 36
DELAYTEMP EQU 112
DELAYTEMP2 EQU 113
ENCODER EQU 37
ENCODER_H EQU 38
FOCUS EQU 39
FOCUS_H EQU 40
HSERRECEIVE EQU 41
OUTVALUETEMP EQU 42
OUTVAR EQU 9118
READAD EQU 43
READAD_H EQU 44
SAVESYSBYTETEMPX EQU 45
SAVESYSTEMP1 EQU 46
SAVESYSTEMP2 EQU 47
SAVESYSWORDTEMPA EQU 48
SAVESYSWORDTEMPA_H EQU 49
SAVESYSWORDTEMPB EQU 50
SAVESYSWORDTEMPB_H EQU 51
SDATA EQU 9100
SERDATA EQU 52
SERPRINTVAL EQU 53
SERPRINTVAL_H EQU 54
SHIFT EQU 55
SHIFT_H EQU 56
SYSBYTETEMPA EQU 117
SYSBYTETEMPB EQU 121
SYSBYTETEMPX EQU 112
SYSCALCTEMPA EQU 117
SYSCALCTEMPX EQU 112
SYSCALCTEMPX_H EQU 113
SYSCHAR EQU 57
SYSCHARCOUNT EQU 58
SYSDIVLOOP EQU 116
SYSDIVMULTA EQU 119
SYSDIVMULTA_H EQU 120
SYSDIVMULTB EQU 123
SYSDIVMULTB_H EQU 124
SYSDIVMULTX EQU 114
SYSDIVMULTX_H EQU 115
SYSINTSTATESAVE0 EQU 59
SYSREPEATTEMP1 EQU 60
SYSREPEATTEMP1_H EQU 61
SYSSTRDATA EQU 62
SYSSTRINGLENGTH EQU 118
SYSSTRINGTEMP EQU 63
SYSSYSINSTRINGHANDLER EQU 64
SYSSYSINSTRINGHANDLER_H EQU 65
SYSTEMP1 EQU 66
SYSTEMP1_H EQU 67
SYSTEMP2 EQU 68
SYSTEMP2_H EQU 69
SYSTEMP3 EQU 70
SYSTEMP3_H EQU 71
SYSTEMP4 EQU 72
SYSTEMP4_H EQU 73
SYSTEMP5 EQU 74
SYSTEMP5_H EQU 75
SYSWAITTEMP10US EQU 117
SYSWAITTEMPMS EQU 114
SYSWAITTEMPMS_H EQU 115
SYSWAITTEMPUS EQU 117
SYSWAITTEMPUS_H EQU 118
SYSWORDTEMPA EQU 117
SYSWORDTEMPA_H EQU 118
SYSWORDTEMPB EQU 121
SYSWORDTEMPB_H EQU 122
SYSWORDTEMPX EQU 112
SYSWORDTEMPX_H EQU 113
TEMP EQU 76
TEMPERATURE EQU 77
TEMPERATURE_H EQU 78
TEMPVAR1 EQU 79
TEMPVAR1_H EQU 80
TEMPVAR2 EQU 81
TEMPVAR2_H EQU 82
TILT EQU 83
TILT_EW EQU 85
TILT_EW_H EQU 86
TILT_H EQU 84
TILT_NS EQU 87
TILT_NS_H EQU 88
TMRPRES EQU 89
TMRSOURCE EQU 90
VAL EQU 91
VAL_H EQU 92
VERSION EQU 93
VERSION_H EQU 94
;**************
;Alias variables
AFSR0 EQU 4
AFSR0_H EQU 5
EEADDRESS EQU 401
EEADDRESS_H EQU 402
EEDATAVALUE EQU 403
SYSCHR_0 EQU 1575
SYSCHR_1 EQU 1576
SYSHSERRECEIVEBYTE EQU 41
SYSREADADINTEGER EQU 43
SYSREADADINTEGER_H EQU 44
SYSSDATA_1 EQU 1470
SYSSDATA_1_H EQU 1471
SYSSDATA_2 EQU 1472
SYSSDATA_2_H EQU 1473
SYSSDATA_3 EQU 1474
SYSSDATA_3_H EQU 1475
SYSSDATA_4 EQU 1476
SYSSDATA_4_H EQU 1477
SYSSDATA_5 EQU 1478
SYSSDATA_5_H EQU 1479
SYSSDATA_6 EQU 1480
SYSSDATA_6_H EQU 1481
SYSSDATA_7 EQU 1482
SYSSDATA_7_H EQU 1483
;**************
;Vectors
ORG 0
pagesel BASPROGRAMSTART
goto BASPROGRAMSTART
ORG 4
INTERRUPT
;**************
;Use Automatic Context Save. Interrupt priority not supported
;Store system variables, if any
movf SysWordTempA,W
movwf SaveSysWordTempA
movf SysWordTempA_H,W
movwf SaveSysWordTempA_H
movf SysWordTempB,W
movwf SaveSysWordTempB
movf SysWordTempB_H,W
movwf SaveSysWordTempB_H
movf SysByteTempX,W
movwf SaveSysByteTempX
movf SysTemp1,W
movwf SaveSysTemp1
movf SysTemp2,W
movwf SaveSysTemp2
;On Interrupt handlers
btfss INTCON,TMR0IE
goto NotTMR0IF
btfss INTCON,TMR0IF
goto NotTMR0IF
call PWMHANDLER
bcf INTCON,TMR0IF
goto INTERRUPTDONE
undefined
Thank you. Your compiler and tool chain is 12 months old. We have changed the USART in the interim period.
However, this may been as simple as BPS support in the chip. Check the datasheet for the problematic BPS at the Mhz you have selected. Changing the Mhz may resolve. The datasheet will detail the BPS errors at specific Mhz.
OK, I tried the latest compiler, but the errors persist. I then had a look at the 16F1829 data sheet and it shows an error of 0.16% at 16MHz and 9600 Baud, so that looks good.
I will stand up a chip here tomorrow.
In the new compiler add
#DEFINE ISSUE_CHECK_USART_BAUD_RATE_WARNINGthis will show the calculated BPS. See the Help for this new constant. If the value is close to 4800 or 9600 then you make want to look at the TTT/USB interface.The warning shows 9615, so probably OK. I'll have a look at the USB side of the circuit - maybe it's a decoupling problem.
If you could look at InitUsart - there registers are obvious and just check the register ( for BPS ) calculate to 9615 BPS. You will find this in the ASM file produced by the compiler for you project.
The new constant is a reverse calculation of the values used to set the BPS. But, there is nothing better than checking the register value being used.
And, do check the Errata. Anything related to the USART ?
Last edit: Anobium 2023-01-07
@Terry - I can see no issues here.
I have tested using your program ( with the call to
ReadTemperaturecommented out.I have tested with FTDI/USB and el cheapo TTL/USB converter - both at 4800 and 9600. Not seen any issues.
My test does resolve the issue at your end. At the moment I have not been able to recreate the situation here.
What is the method
ReadTemperature? Is there some funky stuff going on in that routine?@Terry
Perhaps describe the problem a little better than "intermittent serial data errors when running at 9600 Baud".
Is the problem when sending or receiving (or both)?
What are the symptoms ? Missed characters, wrong characters or something else.
What program or terminal app receives the serial data from the PIC?
You mentioned you are using a FTDI 230XS Chip. Shall we assume this is a commercial module with genuine FTDI chip on it and not one of the many fake/ counterfeits out there?
The FTDI 230X operates at 3.3V I/O levels. Are you also operating the PIC at 3.3V ?
Have you tried adding a delay as a test with < #define USART_DELAY 1 ms >
I have used 16F1829 at baud rates from 9600 up to to 115200 for years without any problems;
Hi William, OK - I'll try to be more precise. Basically, the problem consists of incorrect characters in the data received by the hardware. The software sends 7 byte character strings to the board, which start with a 'command' letter (typically 'G' or 'M') followed by 6 digits. The digital part is a value that the board uses to determine how much a motor will move in response to the command. What happens is that I will see a 'G' or 'M' returned when everything is good, but every few commands, I will get back one of the digits, rather than the command letter. This causes the motor to not respond and often causes a 'time out' on the next command string.
The software in use is well-tried over several years and I can get similar errors when using the GCB terminal to send the strings.
The FT230 is on the board and not in a serial module, so I know that it is a good chip.
The PIC is running at 5 volts.
I've just tried adding the 1 ms delay, but no apparent change is seen.
I have found that the 1 ms delay does nothing at all at 9600. Nothing. To get any delay you must increase it to 2 ms . So try #Define USART_DELAY 2 ms. This will add about 1 ms between bytes sent by the PIC to wherever it is going. This can allow some devices to receive data when more than a few bytes are sent back to back.
It is highly unlikely that the problem is related to inaccurate baud rate on the PIC side. I have an 16F1829 on a breadboard here and with a scope have measured the output baud rate to be 9617. More than good enough for even demanding applications. So unless you have measured the baud rate and found it to be inaccurate I will call that good. The issue lies elsewhere.
What hardware are you referring to ? What is sending the data ?
What software ? Is this your GCB code or some application ?
What board?
What I am trying to get to here is exactly what you are trying to do, where the PIC comes into play, and why you suspect that the PIC or GCB is the root cause of the problem.
Post your complete BASIC code so that I can attempt to see what you are doing. Also post a schematic that shows how the PIC is interconnected with other devices.
In the mean time do try #Define USART_DELAY 2ms and see what happens.
If the issue is related to the PIC receiving data, understand that the PIC has only a 2 byte buffer and each byte/character must be received and then moved quickly into a variable or into an array before the next byte can be received.
William
Good analysis Bill.
If the incoming data is not being appropriately handled then a ring buffer using an interrupt will resolve. But, we need a fuller picture and the complete code.
OK Gents - thanks for the input, but I've now traced the problem to a functional issue in the code. The program uses timer 0 interrupts to generate a steady pulse train for the hardware and it seems that the interrupts can corrupt the serial data when they occur at the wrong moment. Unfortunately, I've not yet found a way to prevent this from happening - any ideas will be very welcome!
You need to share your program. Dont want to guess your ISR.
Hi Anobium, Here is the current version.
So sorry, I was not clear.
The GCB source.
Sorry - I intended to send the source, but mis-clicked!
@Terry
I have examined your code and tried to make sense of it as best I can. There are some significant issues that need to be addressed.
1). The interrupt service routine is way too large. Nothing else can happen while the ISR code is executing. Common practice is to make the ISR as short as possible, set some "flags", and get out.
2). If the HserReceive code is executing and an interrupt is triggered during that time there could be data corruption/ missing data.
3). The interrupt routine is generating a 61 Hz Frame rate for the servos. This should be 50 Hz for analog servos but will be OK for digital servos. You have not said what kind you have.
4). The code seems bloated with the unnecessary use of VAL,CHR to get the data into the proper format.
5). There are unused variables cluttering up the code
6). The general code structure is not very good and is quite inefficient.
7). The variable names are not particularly descriptive. For Example: "cnt"
Nomally "cnt" would be descriptive of a counter of sorts. While you may know the purpose/ function of ''cnt" others like myself looking at the code have to attempt to decipher what it actually does by examining nearly every line of code to make any sense of it.
8). You have never clearly described the project in full and provided any relevant specifications. We do not know what "software" you are using, what the "board" is that you have referred to or even what the actual device is that you are hoping to control. All I know is that it appears to use 2 or three servos, possibly for tilting or panning something and to control the "focus" of something or another (maybe a camera?) We do not know what the "bump" stuff does or is supposed to do. There are no comments in the code to tell us.
My suggestion is to start over with a complete re-write one section at a time. Personally I would not use a timer/interrupt to generate the servo pulses. I would instead use the chips PWM modules and most likely a more modern chip than the 16F1829. Something like a K42 series or even better a Q series. These are all cheap, but admittedly may be hard to source at this time ( global chip shortage). But if you want a recommendation just ask. If you are married to the 16F1829 then so be it. We can try.
We can provide specific help only if we have the specifics of your project ( No crystal balls here and I do not like to guess) ... Otherwise the help will be general and probably not sufficient you get you up and running with such a complex project.
William
A quick note to suggest that an 18F15Q40 should offer pin compatibility with a 16F1829?
Yes that is a good choice and probably a few cents cheaper than the 18F16Q41 that I was going to suggest (my 20 pin favorite). Either of these would be a great alternative. And since these have PPS ( Peripheral Pin Select) the serial I/O and PWM signals can be mapped to almost any pin.
Last edit: William Roth 2023-01-15
@Terry Platt
I may have found the main culprit that is responsible for the data corruption.
On line 102 the code is telling the PIC to sending a data byte while your software/terminal is still sending the 7 byte string. So the next HserReceive after the HSersend is too late to get the next byte. A byte is missed.
Comment out this line and see if this solves the data corruption issue. It did for me.
Alternatively you could have the software that is sending the data to add a 1 or 2 ms transmit delay between each byte.
This may quickly solve you main issue or at least part of it. I
William