 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Dargar
Joined: 12 Dec 2003
Posts: 25
|
| Feedback on some thoughts we have on a project! Thanks! |
 Posted: Sun Jan 18, 2004 3:00 am |
 |
|
Thank you Ttelmah for the quick reply in the recent answer to the topic
found here, I got it almost immidiatly, but I have lingered on the reply.
We are using a PIC16F877 running at 16MHz for this project, and the reason we want to output the actual bits is that we are very bandwidth limited.
What we are doing is sampling 64 analogue channels (8 external 8-to-1 analog MUX'es into the 8 analog inputs on the PIC), adding some frame information once for every 64 samples and then transmitting (in real time) over a 9600 baud radio channel. So by outputting the info converted to hex, wouldn't we loose out on bandwidth? I haven't really thought about it before but wouldn't it be the same as when you convert from a binary representation of a float into a text-float, then each character in the float takes 8 bits (ASCII) to transmit while in binary the whole AD-sample takes only 10 bits?
The reason for the limited bandwidth is that it is a stratospherical science balloon and we are given this bandwidth (to our University) as a courtesy from the owners of the Balloon.
So basically, in the beginning of every 64sample frame, we read a realtime clock, transmit the hours, minutes and seconds and then a synch word "BEXUS" is sent and then the rest is on the format
"channel#"(6bits)+2bit AD data
+8bit AD data
"channel#"(6bits)+2bit AD data
+8bit AD data
and so on.
We are going to use a timer-interrupt to space the sampling at equal intervalls, although I feel very uncertain on how to do this. I see a number of potential issues.
1) if a set timer interrupt between samples is used, we might end up using our TX-link at less than 99%, or WORSE if the timer is off by a little bit, it will accumulate and in the end we will flood the TX-link.
2) ... actually I just see that one at the moment... 
Now, this could be remedied by looking at when the interrupt comes in, if the UART is still buisy with the old transmission, increase the time between interrupts, if it is not buisy then decrease it a little bit. This would hopefully have the effect of "tuning" the sampling rate to the optimal for the bandwidth we have available. One problem:
Since we are using a real-time clock (albeit with a low resolution of only seconds), if the time-intervall in-between samples is not constant (interrupt is changing) then we have no way to calculate at what time the sample is taken (this can be done on the ground if we have a constant sample-rate).
In theory, we should do one 10bit sample every 7.5 seconds as this will together with the synch and RTC data just fill the link to 100%. (If someone doesn't get this to add up, you need to consider that we are taking from the 64 channels and using some of that "space" for the synch and RTC, it might sound stupid but if you had the big picture, it would make more sense. However this is already a long thread, so I will not add to that pages of documentation. If someone REALLY wants to know, they will have to wait a few weeks and I can send a copy of the final report.
Code snips are of course accepted with a big "Thank you" but general advice, warnings of fall-pits and so on is equally valuable to us! -Frankly, the PIC-C version we have seems to "take some getting used to" and we have spent far more time trying to debug examples that should have worked and trying to get things in general to work. some is School-computer (tm) related problems, some are coding errors, and some we don't really know, but we suspect PIC-C. Sometimes we wonder if it would be faster to code in Assembler, but I think not... I've tried that before, it is ...... to debug and develop.
Sorry for the long post, a huge thanks to everyone who made it this far, and I hope for some inputs and warnings and advices![/url] |
|
 |
Ttelmah
Guest
|
| Re: Feedback on some thoughts we have on a project! Thanks! |
| Posted: Sun Jan 18, 2004 4:11 am |
|
|
| Dargar wrote: | Thank you Ttelmah for the quick reply in the recent answer to the topic
found here, I got it almost immidiatly, but I have lingered on the reply.
We are using a PIC16F877 running at 16MHz for this project, and the reason we want to output the actual bits is that we are very bandwidth limited.
What we are doing is sampling 64 analogue channels (8 external 8-to-1 analog MUX'es into the 8 analog inputs on the PIC), adding some frame information once for every 64 samples and then transmitting (in real time) over a 9600 baud radio channel. So by outputting the info converted to hex, wouldn't we loose out on bandwidth? I haven't really thought about it before but wouldn't it be the same as when you convert from a binary representation of a float into a text-float, then each character in the float takes 8 bits (ASCII) to transmit while in binary the whole AD-sample takes only 10 bits?
|
The problem, is a balancing act. You have to remember, that if you are sending pure binary, _any_ byte value may exist. Now in general, if you send a sequence of 'generic' byte values, the possibility exists that patterns may be sent that match your start 'headers', and other framing markers. Hence in general sending like this, means that the headers have to become more complex (to reduce the probability that the patterns may match). In your case, this may not be a problem, since 10bit data (if sent as a 16bit 'packet'), will allways have the high bits in a 'known' state. However you were then talking of sending other data inb these bits, which 're-introduces' the potential problem. I'd also imagine, that the link is either simplex, or half duplex, which implies that the data format must be designed to ensure that re-synchronisation can be done with the least loss of data, and without any 'handshake'.
Hence though hex, has a significant 'size' overhead, it has the 'plus', of allowing the other (non hex) bit patterns to be used as markers.
I have sent data over similar low bandwidth links, and one approach (which may suit), is to packetise the data into 7bit form. Then bytes that have the 'high' bit set, can be reserved for control/synchronisation.
Hence a format like (in binary, but being represented in hex):
AA AA (often needed to 'mark' the start, and allow the radio to sync).
one character time pause.
A5
ID
DATA PACKET
CRC
!ID
Everything _except_ the headers and ID , is sent as seven bit data.
Now the 'key' is that because there is a one character time pause between the 'header' used to ensure the radio TX/RX have synchronised. data reception should start 'in sync', on the A5 character. Then the CRC and inverted ID, allow a check that the packet is complete, and the search for the start marker can begin again.
| Quote: |
The reason for the limited bandwidth is that it is a stratospherical science balloon and we are given this bandwidth (to our University) as a courtesy from the owners of the Balloon.
So basically, in the beginning of every 64sample frame, we read a realtime clock, transmit the hours, minutes and seconds and then a synch word "BEXUS" is sent and then the rest is on the format
"channel#"(6bits)+2bit AD data
+8bit AD data
"channel#"(6bits)+2bit AD data
+8bit AD data
and so on.
|
Most radio links do require a couple of characters to 'wake up', and set the AGC. Hence you should look at sending something like the 'AA' header before the start of the time data.
Though it becomes very unlikely with your relatively complex 'header' marker, you do have the potential for the data being sent to match the header.
| Quote: |
We are going to use a timer-interrupt to space the sampling at equal intervalls, although I feel very uncertain on how to do this. I see a number of potential issues.
1) if a set timer interrupt between samples is used, we might end up using our TX-link at less than 99%, or WORSE if the timer is off by a little bit, it will accumulate and in the end we will flood the TX-link.
2) ... actually I just see that one at the moment...
|
Run a 'countdown' timer. If you have a timer interrupt at (say) 1/100th second, you can use the 'loops' of this to perform one action on each loop. So you set a counter to (say) 200. Then on the first loop, select multiplexer to the first AD channel, then on the next loop, trigger a 'start' on the AD, then on the third loop, read the AD, and select the next channel. On each loop decrement the counter if it is non zero.
Then after 192 loops, all 64 channels will have been read.
In the 'main' code, loop waiting for the counter to = 0.
At this point, you have a new set of data, which can then be sent. to a buffer (use interrupt driven TX to transmit the actual data). As soon as the data has been prepared, and transferred to the buffer, reset the counter to 200, which will restart the sampling. So long as you ensure that the data 'packet', can be transmitted in less time than the time needed to complete the 'countdown', the whole system remains OK, regarding bandwidth. In the example given, this would be one 'packet' every two seconds.
You will need to be _very_ careful about noise design on the PCB. Because data is being transmitted over RF, at the same time as you are trying to read AD samples, really careful design in these area will be vital...
| Quote: |
Now, this could be remedied by looking at when the interrupt comes in, if the UART is still buisy with the old transmission, increase the time between interrupts, if it is not buisy then decrease it a little bit. This would hopefully have the effect of "tuning" the sampling rate to the optimal for the bandwidth we have available. One problem:
Since we are using a real-time clock (albeit with a low resolution of only seconds), if the time-intervall in-between samples is not constant (interrupt is changing) then we have no way to calculate at what time the sample is taken (this can be done on the ground if we have a constant sample-rate).
In theory, we should do one 10bit sample every 7.5 seconds as this will together with the synch and RTC data just fill the link to 100%. (If someone doesn't get this to add up, you need to consider that we are taking from the 64 channels and using some of that "space" for the synch and RTC, it might sound stupid but if you had the big picture, it would make more sense. However this is already a long thread, so I will not add to that pages of documentation. If someone REALLY wants to know, they will have to wait a few weeks and I can send a copy of the final report.
|
You have 64 samples, totalling 1024 bits of data. in a full 'packet'. Add say 48bits for the 'time', and 80 bits for the 'header', plus then (if sending the data as 7bits in 10 transmitted), a link 'overhead' of 1.43*. You can send the entire packet, in 0.172 seconds at 9600bps. Sent in Hex, the entire data packet, would still only be 288bytes, which would only take 0.3 seconds. I think you may be undercalculating your link capacity significantly.
| Quote: |
Code snips are of course accepted with a big "Thank you" but general advice, warnings of fall-pits and so on is equally valuable to us! -Frankly, the PIC-C version we have seems to "take some getting used to" and we have spent far more time trying to debug examples that should have worked and trying to get things in general to work. some is School-computer (tm) related problems, some are coding errors, and some we don't really know, but we suspect PIC-C. Sometimes we wonder if it would be faster to code in Assembler, but I think not... I've tried that before, it is ...... to debug and develop.
Sorry for the long post, a huge thanks to everyone who made it this far, and I hope for some inputs and warnings and advices![/url] |
Best Wishes |
|
|
Guest
|
| Re: Feedback on some thoughts we have on a project! Thanks! |
| Posted: Sun Jan 18, 2004 10:20 am |
|
|
| Quote: | | The problem, is a balancing act. You have to remember, that if you are sending pure binary, _any_ byte value may exist. Now in general, if you send a sequence of 'generic' byte values, the possibility exists that patterns may be sent that match your start 'headers', and other framing markers. Hence in general sending like this, means that the headers have to become more complex (to reduce the probability that the patterns may match). In your case, this may not be a problem, since 10bit data (if sent as a 16bit 'packet'), will allways have the high bits in a 'known' state. However you were then talking of sending other data inb these bits, which 're-introduces' the potential problem. I'd also imagine, that the link is either simplex, or half duplex, which implies that the data format must be designed to ensure that re-synchronisation can be done with the least loss of data, and without any 'handshake'. |
True. And I even wrote it out badly in my first post, so quickly but more cleraly:
64 "channels" divided on 8 "Children/Experiments"=8 Channels pr/child.
Each channel is 2 8-bit words wide.
The time-stamp and Synch word acutally counts as one "Child" = 16bytes
arranged like this:
[BEXUS][Hour][Minutes][Seconds][BEXUS][Hour][Minutes][Seconds]
The synch and time data is sent twice creating a long synch pattern to look for, even though the time changes in between frames.
In addition, we will "know" when to look for it because of the way the 56 "channels" are constructed.
Word1 [Address 6bit wide][2MSB from ADC]
Word2 [8LSB from ADC]
From the Adress data, we know when the last channel on the final child gets down, and can thus predict when to expec the synchs.
| Quote: | | Hence though hex, has a significant 'size' overhead, it has the 'plus', of allowing the other (non hex) bit patterns to be used as markers. |
not following here (but I'm working 14 hour days now so bear with me.
8 bits = 256 = FF. what is the other (non hex) bit patterns you speak off? Any bit code can be converted to hex so there are no non-hex patterns?
[qoute]
I have sent data over similar low bandwidth links, and one approach (which may suit), is to packetise the data into 7bit form. Then bytes that have the 'high' bit set, can be reserved for control/synchronisation.
Hence a format like (in binary, but being represented in hex):
AA AA (often needed to 'mark' the start, and allow the radio to sync).
one character time pause.
A5
ID
DATA PACKET
CRC
!ID
Everything _except_ the headers and ID , is sent as seven bit data.
Now the 'key' is that because there is a one character time pause between the 'header' used to ensure the radio TX/RX have synchronised. data reception should start 'in sync', on the A5 character. Then the CRC and inverted ID, allow a check that the packet is complete, and the search for the start marker can begin again.
Most radio links do require a couple of characters to 'wake up', and set the AGC. Hence you should look at sending something like the 'AA' header before the start of the time data.
Though it becomes very unlikely with your relatively complex 'header' marker, you do have the potential for the data being sent to match the header.
[/qoute]
True true, I'm sorry for not beeing clearer. The radio link we have available is a "black box" separte from all our electronics, it has 3 input channels (RS-232, 2 * 9600 and 1 * 4800) of which we have been assigned one 9600. We don't have to concern ourselves with anything when it comes to "preamble" and keeping our bit-change-rate as high as possible (sending a long stream of '1's on a radio-link is not good) and they have (we assume) built in protocol including CRC (or better). On the ground they give us three outputs with hopefully the same data as we are trying to send, minus lost packages and corrupted transmissions.
If data resembles the header (remote chance) then thats to bad. All data is dumped into a raw file for post-processing as well as beeing limited real-time processed, so such things can be cleared up at post-processing unless data is really screwed up with lots of lost chunks, in which case: too bad. Becuase of time and money constraint on us, the students, we will have to accept that. (We are doing this on our spare time with a very limited money and time budget.)
[qoute]
Run a 'countdown' timer. If you have a timer interrupt at (say) 1/100th second, you can use the 'loops' of this to perform one action on each loop. So you set a counter to (say) 200. Then on the first loop, select multiplexer to the first AD channel, then on the next loop, trigger a 'start' on the AD, then on the third loop, read the AD, and select the next channel. On each loop decrement the counter if it is non zero.
Then after 192 loops, all 64 channels will have been read.
In the 'main' code, loop waiting for the counter to = 0.
At this point, you have a new set of data, which can then be sent. to a buffer (use interrupt driven TX to transmit the actual data). As soon as the data has been prepared, and transferred to the buffer, reset the counter to 200, which will restart the sampling. So long as you ensure that the data 'packet', can be transmitted in less time than the time needed to complete the 'countdown', the whole system remains OK, regarding bandwidth. In the example given, this would be one 'packet' every two seconds.[/quote]
I've been thinking, the best way to maintain 100% efficiency risk free is to have an interrupt telling me when it has completed the previous transmission.
interrupt->send next data & start sampling and preparing next data set
As long as the preparation of the next data does not take longer than to transmitt 16 bits (two interrupts, I know) we will be okay.
| Quote: |
You will need to be _very_ careful about noise design on the PCB. Because data is being transmitted over RF, at the same time as you are trying to read AD samples, really careful design in these area will be vital...
|
I don't know too much about it, we had two hours on EMC designs in general.... however, since the RF unit is running on a different battery/power system in a different box removed from us and the only link in-between is a standard RS-232 cable, we should be "safer" right?
The inputs to the PIC ADC will be put through a simple RC lowpass filter very close to the PIC. Tests with an oscilloscope shows that 7kHz noise is attenuated by 16db will 200Hz> signlas are not affected. The analog signals are also (prior to filter) op-amp adjusted for a 0 to 5V level.
| Quote: |
You have 64 samples, totalling 1024 bits of data. in a full 'packet'. Add say 48bits for the 'time', and 80 bits for the 'header', plus then (if sending the data as 7bits in 10 transmitted), a link 'overhead' of 1.43*. You can send the entire packet, in 0.172 seconds at 9600bps. Sent in Hex, the entire data packet, would still only be 288bytes, which would only take 0.3 seconds. I think you may be undercalculating your link capacity significantly.
|
So do I. My calculations made perfect sense when I did them, now I don't know anymore.
64 "channels" * 16 bits = 1024 bits of data. Add nothing because the header and time is a part of the 64 "channels" and nothing because we don't have to preamble the RF-unit, and we have a grand total of 1024 bits to transmitt. On a 9600 baud link we get 9600/1024=9.375 "chunks"/second..
BUT if the baudrate is 9600, don't we have to consider the 1 start bit and the 1 stop bit? e.g. 1024+(2*128) = 1280 bits to transmit => 7.5 "chunks"/seconds, as per my original calculations??
I have told all the people making the experiments that my team will "serve" that we will sample at ~7.5Hz on each of the channels, I'm sure they will be glad if we go faster, but what should I write in my report? Should I or should I not take into consideration the start and stop bit in the RS-232 com? Is 9600baud the same as 9600 DATA bits/second, I seem to remember that it means transitions/second, and that indicates that I should take into acount all bits (transitions) and not just the data ones?
Snip: | Quote: | | Sent in Hex, the entire data packet, would still only be 288bytes |
end of snip.
If I arrange the "to send data" in 8 bit variables (int) and use printf("%c", intvariable) wouldn't that work as I want it to, without creating an overhead? True, you couldn't read the raw-data directly, except for the "BEXUS" string appearing in the synch. but since we are going to post-process it wouldn't matter would it? And I wouldn't loose any data even if the 8 bits translates to an invisible char, since it is still a char? Would the CCS compiler do something funny if I try to printf("%c") an integer?
Thank you, we will all need it. I want you all to know that we are truely gratefull for the time you all take reading this, and we try to show this appreciation by writing out all the facts to keep any unclarities out of the way. Also, we hope that by taking the time to write longer and more detailed, we might help others with problems too, since they can easily see whats going on, so to speak.
We hope for a nice responce yet again, and hope that we have not made anyone fall asleep yet. |
|
|
John P
Joined: 17 Sep 2003
Posts: 331
|
|
| Posted: Sun Jan 18, 2004 1:07 pm |
|
|
My favorite method for this kind of thing is to send a stream of packets beginning with a start byte that's always the same value. There's no attempt made to keep this byte from being used as data, but if it occurs, it gets sent twice. Also, the packet is either always the same length, or contains a length byte near the beginning to tell the receiver what to expect, and there's a checksum at the end. The integrity of a packet can thus be checked various ways (length correct, checksum matches, no un-doubled start bytes seen). If you need to avoid "dead air" you can always send padding bytes between packets. In theory the packet could be any length you want, but since if a packet fails it has to be thrown away in its entirety, it's best to limit the length somewhat.
Is this even an appropriate response to the problem? I'm not sure I understand what the issues are. |
|
|
Ttelmah
Guest
|
| Re: Feedback on some thoughts we have on a project! Thanks! |
| Posted: Sun Jan 18, 2004 1:11 pm |
|
|
| Anonymous wrote: | | Quote: | The problem, is a balancing act. You have to remember, that if you are sending pure binary, _any_ byte value may exist. Now in general, if you send a sequence of 'generic' byte values, the possibility exists that patterns may be sent that match your start 'headers', and other framing markers. Hence in general sending like this, means that the headers have to become more complex (to reduce the probability that the patterns may match). In your case, this may not be a problem, since 10bit data (if sent as a 16bit 'packet'), will allways have the high bits in a 'known' state. However you were then talking of sending other data inb these bits, which 're-introduces' the potential problem. I'd also imagine, that the link is either simplex, or half duplex, which implies that the data format must be designed to ensure that re-synchronisation can be done with the least loss of data, and without any 'handshake'.
True. And I even wrote it out badly in my first post, so quickly but more cleraly:
64 "channels" divided on 8 "Children/Experiments"=8 Channels pr/child.
Each channel is 2 8-bit words wide.
The time-stamp and Synch word acutally counts as one "Child" = 16bytes
arranged like this:
[BEXUS][Hour][Minutes][Seconds][BEXUS][Hour][Minutes][Seconds]
The synch and time data is sent twice creating a long synch pattern to look for, even though the time changes in between frames.
|
This also makes it very unlikely that any 'sync' character will occur accidentally. Good news. :-)
| Quote: |
In addition, we will "know" when to look for it because of the way the 56 "channels" are constructed.
Word1 [Address 6bit wide][2MSB from ADC]
Word2 [8LSB from ADC]
From the Adress data, we know when the last channel on the final child gets down, and can thus predict when to expec the synchs.
Hex has the 'plus', of allowing the other (non hex) bit patterns to be used as markers.
not following here (but I'm working 14 hour days now so bear with me.
8 bits = 256 = FF. what is the other (non hex) bit patterns you speak off? Any bit code can be converted to hex so there are no non-hex patterns?
|
Hex, is just 16 possible codes out of 256 (using 8bit data). Only the characters 0-9, A-F, are legitimate 'Hex' characters in transmission. You can code any binary character as 'Hex', but need two Hex characters to transmit one 8bit binary character.
| Quote: |
I have sent data over similar low bandwidth links, and one approach (which may suit), is to packetise the data into 7bit form. Then bytes that have the 'high' bit set, can be reserved for control/synchronisation.
Hence a format like (in binary, but being represented in hex):
AA AA (often needed to 'mark' the start, and allow the radio to sync).
one character time pause.
A5
ID
DATA PACKET
CRC
!ID
Everything _except_ the headers and ID , is sent as seven bit data.
Now the 'key' is that because there is a one character time pause between the 'header' used to ensure the radio TX/RX have synchronised. data reception should start 'in sync', on the A5 character. Then the CRC and inverted ID, allow a check that the packet is complete, and the search for the start marker can begin again.
Most radio links do require a couple of characters to 'wake up', and set the AGC. Hence you should look at sending something like the 'AA' header before the start of the time data.
Though it becomes very unlikely with your relatively complex 'header' marker, you do have the potential for the data being sent to match the header.
|
True true, I'm sorry for not beeing clearer. The radio link we have available is a "black box" separte from all our electronics, it has 3 input channels (RS-232, 2 * 9600 and 1 * 4800) of which we have been assigned one 9600. We don't have to concern ourselves with anything when it comes to "preamble" and keeping our bit-change-rate as high as possible (sending a long stream of '1's on a radio-link is not good) and they have (we assume) built in protocol including CRC (or better). On the ground they give us three outputs with hopefully the same data as we are trying to send, minus lost packages and corrupted transmissions.
If data resembles the header (remote chance) then thats to bad. All data is dumped into a raw file for post-processing as well as beeing limited real-time processed, so such things can be cleared up at post-processing unless data is really screwed up with lots of lost chunks, in which case: too bad. Becuase of time and money constraint on us, the students, we will have to accept that. (We are doing this on our spare time with a very limited money and time budget.)
Run a 'countdown' timer. If you have a timer interrupt at (say) 1/100th second, you can use the 'loops' of this to perform one action on each loop. So you set a counter to (say) 200. Then on the first loop, select multiplexer to the first AD channel, then on the next loop, trigger a 'start' on the AD, then on the third loop, read the AD, and select the next channel. On each loop decrement the counter if it is non zero.
Then after 192 loops, all 64 channels will have been read.
In the 'main' code, loop waiting for the counter to = 0.
At this point, you have a new set of data, which can then be sent. to a buffer (use interrupt driven TX to transmit the actual data). As soon as the data has been prepared, and transferred to the buffer, reset the counter to 200, which will restart the sampling. So long as you ensure that the data 'packet', can be transmitted in less time than the time needed to complete the 'countdown', the whole system remains OK, regarding bandwidth. In the example given, this would be one 'packet' every two seconds.
I've been thinking, the best way to maintain 100% efficiency risk free is to have an interrupt telling me when it has completed the previous transmission.
interrupt->send next data & start sampling and preparing next data set
As long as the preparation of the next data does not take longer than to transmitt 16 bits (two interrupts, I know) we will be okay.
| Quote: |
You will need to be _very_ careful about noise design on the PCB. Because data is being transmitted over RF, at the same time as you are trying to read AD samples, really careful design in these area will be vital...
|
I don't know too much about it, we had two hours on EMC designs in general.... however, since the RF unit is running on a different battery/power system in a different box removed from us and the only link in-between is a standard RS-232 cable, we should be "safer" right?
The inputs to the PIC ADC will be put through a simple RC lowpass filter very close to the PIC. Tests with an oscilloscope shows that 7kHz noise is attenuated by 16db will 200Hz> signlas are not affected. The analog signals are also (prior to filter) op-amp adjusted for a 0 to 5V level.
|
No.
You _may_ have problems. Remember that if you are using a 10bit AD converter, with a 2.5v reference, one 'bit' will be just 2.5mV. RF near to you, _will_ induce noise in the signals, as will the PIC itself performing it's processing (this is why if you want the best AD performance, you should stop the processor, while performing the AD conversion). The RC filter will help, but look at careful ground design, between the AD reference, and the incoming signals. Keeping the signal clean, and preventing errors from the noise, will be the hardest part in the whole project!...
| Quote: |
You have 64 samples, totalling 1024 bits of data. in a full 'packet'. Add say 48bits for the 'time', and 80 bits for the 'header', plus then (if sending the data as 7bits in 10 transmitted), a link 'overhead' of 1.43*. You can send the entire packet, in 0.172 seconds at 9600bps. Sent in Hex, the entire data packet, would still only be 288bytes, which would only take 0.3 seconds. I think you may be undercalculating your link capacity significantly.
|
So do I. My calculations made perfect sense when I did them, now I don't know anymore.
64 "channels" * 16 bits = 1024 bits of data. Add nothing because the header and time is a part of the 64 "channels" and nothing because we don't have to preamble the RF-unit, and we have a grand total of 1024 bits to transmitt. On a 9600 baud link we get 9600/1024=9.375 "chunks"/second..
BUT if the baudrate is 9600, don't we have to consider the 1 start bit and the 1 stop bit? e.g. 1024+(2*128) = 1280 bits to transmit => 7.5 "chunks"/seconds, as per my original calculations??
I have told all the people making the experiments that my team will "serve" that we will sample at ~7.5Hz on each of the channels, I'm sure they will be glad if we go faster, but what should I write in my report? Should I or should I not take into consideration the start and stop bit in the RS-232 com? Is 9600baud the same as 9600 DATA bits/second, I seem to remember that it means transitions/second, and that indicates that I should take into acount all bits (transitions) and not just the data ones?
Snip: | Quote: | | Sent in Hex, the entire data packet, would still only be 288bytes |
end of snip.
If I arrange the "to send data" in 8 bit variables (int) and use printf("%c", intvariable) wouldn't that work as I want it to, without creating an overhead? True, you couldn't read the raw-data directly, except for the "BEXUS" string appearing in the synch. but since we are going to post-process it wouldn't matter would it? And I wouldn't loose any data even if the 8 bits translates to an invisible char, since it is still a char? Would the CCS compiler do something funny if I try to printf("%c") an integer?
Thank you, we will all need it. I want you all to know that we are truely gratefull for the time you all take reading this, and we try to show this appreciation by writing out all the facts to keep any unclarities out of the way. Also, we hope that by taking the time to write longer and more detailed, we might help others with problems too, since they can easily see whats going on, so to speak.
We hope for a nice responce yet again, and hope that we have not made anyone fall asleep yet.[/quote]
You posted 7.5 seconds, not 7.5Hz...
A rather significant difference.
At 7.5Hz, you may have worries about the speed of the AD converter. If you are taking 64 samples, each one needs to be selected (time for the MUX to switch), allowed to hold for the acquire time, then sampled. This may not be nearly as fast as you think. For simple dats, just use putchar, don't bother with printf (using %c, the results are the same).
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
