 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : MaxiMite serial out - extra LF byte?
Page 1 of 3   |
|||||
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9309 |
Hi folks. 
I am having large amounts of trouble, trying to interface to a pager transmitter. It would seem that there are extra LF bytes being sent by the COM port. Try this code: Open "COM1:9600" As #1 Print #1, "Hello." + chr$(13) Pause 100 Close #1 When you run this, I am getting an extra LF on the end of this, or so it would seem. The pager transmitter keeps complaining that the message length is wrong. When I connect to a terminal, and run the code example above, I am getting extra line-feed's between the wanted output, and the next attempt, which is confusing the transmitter, and it is reporting there is an error with respect to message length, which I could believe. Can anyone throw any light on this? EDIT: Yes, if I remove the chr$(13) on the end of the string, then run that, the code still produces a LF at the end of the output. Bug? Smoke makes things work. When the smoke gets out, it stops! |
||||
jman Guru  Joined: 12/06/2011 Location: New ZealandPosts: 711 |
This should sort it Regards Jman |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9309 |
Cheers, matey - I will try this now.... EDIT: Initial terminal tests say this is good advise.  Will now try it with the actual transmitter.....
EDIT: No, transmitter still does not like it - keeps reporting message length error. I have driven these transmitters with PICAXE all the time, so there must be something I am overlooking or otherwise not seeing. I might build a test circuit that will input each and every byte and show it's ASCII value - a disassembler of sorts - to see exactly what bytes are being sent..... I am using the CMM2 and it's 232 interface chip etc, and it is working OK out to a PC terminal, but the transmitter itself is not liking the data. As I am using a 232 chip, I don't think I need any pull-ups or pull-downs on either side of the link, as from what I remember, the 232 chip does all that for me.... EDIT: I have just done more tests, and even with the ; to supress the output of CR/LF, we are still getting LF on the end of serial output, so it would seem. Open "COM1:9600" As #1 Print #1, "Hello." + chr$(13) Pause 100 Close #1 ...gives me unwanted LF bytes, but: Open "COM1:9600" As #1 Print #1, "Hello."; Print #1,Chr$(13) Pause 100 Close #1 ...also adds unwanted LF bytes to the output.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Frank N. Furter Guru Joined: 28/05/2012 Location: GermanyPosts: 831 |
Hi Grogster, did you tried this? Print #1, "Hello." + chr$(13);
The semicolon on the end should eliminate the wrong CR. I had this problem time ago with Maximite... Frank |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3816 |
In each case you need a ; i.e. chr$(13); to suppress the LF John |
||||
| Goeytex Regular Member  Joined: 12/05/2014 Location: United StatesPosts: 74 |
Is that the complete code? Or are you looping ? Suggest you remove the "Close #1" and try again. Every time a close #1 executes, a 3us low pulse is generated on pin21. This little pulse is seen by my Saleae Logic as a "255" or as a start bit. Is there a reason you are closing the port ? Try this: [code] Open "COM1:9600" As #1 pause 10 Do Print #1, "Hello." + CHR$(13) '// 7 bytes Pause 1000 loop [/code] This works fine on a MicroMite, seven bytes with the last being a CR. I would think the same on a Maximite. Attached is a capture from the Logic Analyzer. 
Note that the serial data is Idle High. Do you need to invert ? |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
There was a bug some time ago in DOS MMBasic that did exactly that Extra LF in Dos MMBasic. Geoff fixed it in V4.3A (see the changelog). Have a look at your output with a hex editor, it should show it if its there. Greg |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9309 |
Where can I find a hex editor, so that I can see if the extra byte really is there? Being an unprintable byte, you can't "See" it, if you know what I mean... @ Goeytex - I have tried looping, and not looping. At the moment, all I am doing, is what is listed in the code - it just runs once, but leaves COM1 open, so that I can then run experiments at the command prompt by directly issuing commands. I am using the CMM2's on-board 232 level-corrector, so what is coming out of there should be RS232, which is what the pager transmitter wants, and if I hook to a terminal, I am getting the wanted output OK, but seem to be getting these extra LF bytes. Right now, I really need a hex editor, as sugested by paceman. @ JohnS - Yes, that is a point - I am probably getting an automatic LF after my chr$(13) command - will experiment now. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9309 |
Nope. Still getting LF at the end, even with ; on the end of chr$(13) So, my current testing code is: Open "COM1:9600" As #1 Start: Print #1,"Hello world." + chr$(13); Print "."; Pause 1000 Goto Start This just prints a dot on the screen for each loop, so I can just get an idea of how many times it has looped, and the Print #1,"Hello world." + chr$(13); DOES NOT suppress the CR/LF at the end of the line. See this image: 
Now, if I change the line in the code to Print #1,"Hello world."; then it works to a point - see this image: 
Now, that IS correct, so if I change the code above to: Open "COM1:9600" As #1 Start: Print #1,"Hello world."; Print #1,chr$(13); Print "."; Pause 1000 Goto Start ...then it goes back to individual lines of "Hello World." - IE, the LF is not being suppressed. Here is an image from a HEX editor - I don't know what it means, but some of you will be able to work it out. 
I captured this in TeraTerm, then opened it with TinyHexer. UPDATE: If I send just ONE cycle of this to TeraTerm, having first set it up to log bytes, then the line Print #1,"Hello world." + chr$(13); outputs 12 bytes - just the message, and ignores the + chr$(13); completely. If I change the code to the one where there is the ; on the end of the hello world message, and print #1,chr$(13) on the next line, I still only get 12 bytes - the message, with no CR or LF at all - code is totally ignoring the line Print #1,chr$(13); The tinkering continues.... Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6102 |
It depends a lot on how you have your terminal program set up. You usually have the option to automatically add the CRLF pair if only one of them is received. That makes debugging your code difficult! At first glance, your terminal program is seeing the CHR$(13) and adding the LF to advance to the next line. Without that, the CR your are sending will cause the line of text to be overwritten. The HEX example you gave shows the text without any CR or LF which agrees with the 'hello world.' all on one line. Jim VK7JH MMedit MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9309 |
OK, here is another experiment. Open "COM1:9600" as #1 Start: Print #1,"Hello world."; Print #1,Chr$(13) Print "." End This produces the following file: 
Note that the line Print #1,Chr$(13) seems to be adding LF weather you actually want it or not... Now, if I remark out that line(the 'Print #1,Chr$(13)' line), then I get the following output: 
So, it looks like MMBasic is adding an unwanted LF byte there unless I am misunderstanding things, which would not be a first!!!!  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9309 |
@ Jim - you have a point there - perhaps the terminal software is screwing with things. Does anyone know of any software which will just save the bytes received without any translation at all? Smoke makes things work. When the smoke gets out, it stops! |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Grogster, You will not believe this, however, I have just gone through the same thing and just about hung up my hat until this thread came about just in time. I am working with a motion control board that uses serial commands. When sending a command string to the motion control board, the mcb always will respond with an * unless there is an error. One of the commands is to send an "I" after commanding a motion and the unit will not respond with an * until the motion is complete. For the life of me, I could not get this to work. After sending the "I", I would get and immediate * even though the motion was not complete. After reading this thread, it dawned on me that I was sending the I along with a LF because I didn't include the ; after the I. Once the ; was added, all is well with the world. So I can tell you with certainty that the ; suppresses anything that would come after. When I use the command PRINT #1, "I";, nothing else is sent but the I. I cannot thank you guys enough, once again, for saving my sanity!!!! I am suspecting that your terminal program is giving you some bad info maybe. Please keep us posted as to your progress and any conclusions you come across with this. I forgot to mention that I am using a uMite. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9309 |
Hi there. Thanks for your post, and I am glad you got your unit working.
My next step will be to hook up another MaxiMite and screen, so that I can send bytes from the first one, to the second one's input buffer, then I can examine exactly what is being sent, and rule out any potential terminal translation issues. Still does not explain why the pager transmitter won't respond - it keeps saying the command length is wrong. One of the commands you can send the trasmitter is "map<cr>", which will show on the terminal screen, all the internal settings etc. This won't even work - keeps coming back with syntax errors. I have interfaced PICAXE chips to these exact transmitters on at least a couple of occasions, and they work fine, so I still think there is a rouge byte in the mix there somewhere.... I will hook up the 2nd MM shortly, and write a simple code to run on it, which will just read the contents of the serial buffer, and show the byte values on the screen. Will post back later. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9309 |
MaxiMite most definetly IS adding unwanted bytes to the serial output. I have linked two MaxiMites togeather, and one transmits to the other, then the 2nd one reads out the bytes from the serial buffer. Here is the "Sender" code: 
...and here is the "Receiver" MM code: 
Now, if I run the receiver code first(so it is ready for action), then run the sender code with the two MM's linked togeather, I get the following on the receiver MM: 
Note that the MM is appending an extra CR/LF(13/10) to the end of the data sent out of the COM1 serial port on the first MM(the 'Sender') So, in a nutshell, we have two extra unwanted bytes being sent, which is why the pager transmitter is replying with syntax errors - the transmitter is correct. Can anyone think of a workaround for this? BOTH MM units have the same firmware, which is version 4.4 - perhaps this is the source of my problems??? Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9309 |
OK, another update - once I change the line to Print #1,"Hello world." + chr$(13);, this IS giving just the <cr> at the end, so I think that perhaps my fecking terminal software was adding LF bytes and was confusing the situation. I will now change that code so that it just says "map<cr>" and connect via the 232 corrector to the pager transmitter, and see if I get a response..... Smoke makes things work. When the smoke gets out, it stops! |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6102 |
I do happen to know of a terminal program that lets you see what really is coming in. MMEdit can be used as a basic terminal program and you can switch between ASCII and HEX easily. In HEX mode it shouldn't be doing any strange things to the data. Jim VK7JH MMedit MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9309 |
Nope. Pager transmitter totally ignores the attempt to send it the map command. If I plug the laptop directly into the transmitter, I can command it just fine. I wonder if I have a crook transmitter or something? I will see if I can find another one to test. I also have a cellphone module, so will hook this up and see if I can get a response out of it. Smoke makes things work. When the smoke gets out, it stops! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
The line: Print #1,Chr$(13) is missing the semicolon, this is why you are getting two extra characters. The semicolon definitely suppresses the CR/LF. Geoff Geoff Graham - http://geoffg.net |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I always check output to a serial port by first printing to the screen (console) by changing the Print #1, "Tekst" to a Print "Tekst" If there are many places where data is send i put an identifier in front like: Print "#1#Tekst" I then get the output on the console so that i can check it very carefully. Adding the ";" will be very clear to see. If everything is ok, then i add the "#1, " part to the print statement. Microblocks. Build with logic. |
||||
| Page 1 of 3 |
|||||
 Print this page |
