Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

Hi

I have a Logger that sends data (about 80 characters) every minute to
the hardware serial port. This data is collected by a PC and
everything is fine up to here.

The only thing is that I get extrange characters at the end of the
line (like little square boxes, about 4 of them). If I later try to
open the file in Notepad, it is fine but if I try to import it in
Excel, Windows takes this extra characters as a carriage return (CR)
so I end up with a blank line between every line of data I have.

Any way to stop this happenning? This has happened in every single
logger I have built using LCDX.

Please, any hints on this... I don't know what else to try.

Example of data:

V 0 A 0.0 K 0.0 W 0.0 D 0.0 R 0.0 M 0.0 T 0.00 H 3 M 18

V 0 A 0.0 K 0.0 W 0.0 D 0.0 R 0.0 M 0.0 T 0.00 H 3 M 18

V 0 A 0.0 K 0.0 W 0.0 D 0.0 R 0.0 M 0.0 T 0.00 H 3 M 18

V 0 A 0.0 K 0.0 W 0.0 D 0.0 R 0.0 M 0.0 T 0.00 H 3 M 18

V 0 A 0.0 K 0.0 W 0.0 D 0.0 R 0.0 M 0.0 T 0.00 H 3 M 18

Even here I get the double line. In notepad I didn't have it and I
copied and pasted here and voila!! Double space.

Thanks

Ed





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Well, would bet that they ARE a carriage return and line feed.

What are the numerical values of the characters?

The solutojn is to NOT use debug.print, and just place the
characters in an output queue yourself. Easy to do and quite
efficient. This way nothing does any translation or addition of
characters. You control everything!

If RAM is at a premium and you can't afford to lose the 20 or more
bytes of memory to support the queues, then maybe you could
interract with the hardware UART of the AVR. I have not done it
personally, but it should not be terribly hard. You probably do not
have to set the UART speed, because it is already set. Probably all
you need to do is to place the character in the proper register of
the AVR.

Needless to say, it is much easier just to set up a 10 byte input
and output queue, then configure the COM1 port to your needs, then
place the characters in the queue after checking that the queue is
ready to take another character. That is literally the entire
process!

-Tony -Tony





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "Ed" <esteyezz@y...> wrote:
> ... I get extrange characters at the end of the line [produced
> by Debug.Print].

If you need a single end-of-line character or record marker one
solution is to not let Debug.Print add the EOL and put your own on.
Example:

Dim eolChar as Byte
...
eolChar = &H0a ' linefeed
...
Debug.Print CStr(var1); " "; CStr(var2); Chr(eolChar);

The trailing semicolon prevents Debug.Print from adding
the "standard" EOL of CR and LF.

Since Debug.Print is known to use lots of stack space you might be
better off, RAM-wise, to opt for Tony's suggestion and use a
separate queue.

Don



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I tryed using a similar approach:

Debug.Print CStr(var1); " "; CStr(var2); Chr(13);

but didn´t seem to do much better. I will give a try to your suggestion.

Memory so far is not a problem, if I used Debug.Print is because
lazyness. The application reads continuosly from the ADC I/O ports and
sends data every minute to the serial port.

If the Hex version doesn´t work, then I will try with the buffers.

Thanks for the feedback

Ed

--- In basicx@basi..., "Don Kinzer" <dkinzer@e...> wrote:
> to not let Debug.Print add the EOL and put your own on.




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "Ed" <esteyezz@y...> wrote:
>Debug.Print CStr(var1); " "; CStr(var2); Chr(13);

Your receiving software on the PC may be translating either CR or LF
or both to a CRLF pair. With some experimentation or reading the
documentation/code for the receiving app you should be able to figure
out what to send in order to end up with what you want. The receiving
app may also be configurable with respect to how it handles line ends.

Don



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )