Serin problems

Smedly

New Member
Hello.
I've run out of ideas to get my current project running and hope someone else might be able to give me some ideas. Im fairly familiar with the Picaxe system and don't usually have this level of frustration.
The project - I need to retrieve a single data byte from a solar regulator to keep it in sync with another battery charging device. The regulator uses Modbus at 9600 via RS233.
I can send the required 8 byte string to the regulator and get the correct 7 byte answer back while using the terminal window within the editor program, via an Aten USB to RS232 converter, so I know the data strings and the CRCs are correct.
However. When I connect up my 14M2 and use the serout and serin commands at T9600 I don't get an answer back. Am connecting the Picaxe to the regulator via TTL to RS 232 converter. If I plug the out put of this converter into another computer via its RS232 connection I see the correct string being sent so I'm assuming that the serout command is working properly and that the serin command might be the culprit. I've got the serin command directly after the serout command.
So before I throw it at the wall has anyone got any ideas? Would be greatfull for any advice.
 

Flenser

Senior Member
Smedley,

You should post the code you are running on the 14M2 so that the forum can inspect it as a part of investigating your problem.
 

Smedly

New Member
Hi Flenser.
Thanks for the speedy responce. Code below - I hope.

Code:
Main:        pause 2000
        low C.0
        low C.1
        low B.0
        low B.1
        low B.2
        low B.3
        low B.4
        low B.5
        setfreq m8
        pause 200
        'serout C.4,T9600_8,($01,$03,$00,$32,$00,$01,$25,$C5)    'ask for reg charge state pin 5
        serout C.4,T9600_8,(1,3,0,50,0,1,37,197)            'pin 5
        serin [2000,Nodata],C.2,T9600_8 ,b1,b2,b3,b4,b5,b6,b7    'receive serial data pin 6
        setfreq m4
        pause 200
        sertxd ("Recieved data = ",b1,b2,b3,b4,b5,b6,b7,13,10)    'send received data to terminal
        pause 2000                                'wait 2 seconds
        goto main

Nodata:        setfreq m4
        pause 200
        sertxd("No data recieved",13,10)            'it didn't work - most likely outcome
        goto main
 

Flenser

Senior Member
Smedley,

I can't see anything wrong with your code.

The manual makes thes these two comments about the serin command:
Note that the microcontroller may not be able to keep up with processing complicated datagrams at higher speeds
A maximum of 4800 baud is recommended for complicated serial transactions at 8MHz.
Based on this I have two suggestions you could try:
1. Test using M16 or M32 instead of M8 with your serout and serin, at the matching T9600_16 or T9600_32, to check if it is a problem receiving 9600 baud at 8MHz
2. Test changing your serin command to just receive one character, instead of the full 7, to check if it is a problem with the chip keeping up receving all 7 characters in a row.
i.e. something like this for M16:
Code:
serin [2000,Nodata],C.2,T9600_16 ,b1
Also, what chip are you using?
 

darb1972

Senior Member
Flenser, I think Smedley is using a 14M2.

Smedley, I'll throw out a wild idea and suggest you try inverting with N9600 (even though you had success with T9600 via the terminal window). Maybe the Aten USB is inverting the signal after the terminal.

Worth a try.
 

AllyCat

Senior Member
Hi,

Yes, certainly try M32 in case the PICaxe can't keep up with the 9600 baud. Note that you may also need to increase the timeout delay !

You say you receive "no answer", but try putting a # before each byte variable in the SERTXD command (i.e. ...#b1,#b2,#b3.. etc.) in case you are actually receiving "unprintable" (corrupted) characters (which might occur if the PICaxe is struggling or has inverted polarity).

Finally, if it is "T" polarity then there is the possibility of using the HSERIN (hardware) command to receive the data. It's not on very convenient pins with the M2s, but it is possible.

Cheers, Alan.
 

PhilHornby

Senior Member
... so I'm assuming that the serout command is working properly and that the serin command might be the culprit..
One observation on your code: the very first Serout won't work properly, without an initial High C.4. (The serout doesn't set the line high before starting transmission ... but does leave it high afterwards.) However, since the code runs in a loop, it will work from the 2nd attempt onwards.

It could be that the 'regulator' is replying too quickly for the Picaxe. By this I mean, it has already started transmitting, before the Picaxe has processed the serin. Try printing the contents of b1->b7 at the nodata label, instead of just saying "no data received"; you may find you received part of the response. (You should probably clear these values each time round the loop, for 'completeness').

If it is a timing issue, then setfreq M32 will definitely help. Also, you could switch to hserout instead of serout. hserout completes before the UART has finished transmitting the last byte - thus buying you 1mS or so to get the serin up and running.

(Using hserout will mean you can no longer use Sertxd though, because it's on a fixed pin - I can't remember if it's a function that can be remapped to an alternative pin...)
 

Smedly

New Member
Thanks a lot for all those sugestions. I'll get back onto it this morning and let you know how it goes.
 

Smedly

New Member
Well I'm still stumped. Its getting serious now. Ive connected the oscilloscope up and have looked at the two different signals. The data from the USB to RS232 converter looks almost the same as what's coming out of my Picaxe via the TTL to RS232 converter - a MAX232 on a board with a nine pin D connector.
The idle voltages are slightly different but not by too much. Once I've got the Txd connected to the Solar reg I get back the correct idle voltage on the Rxd so its definitely seeing the connection. But why does one converter work and the other not? Do I need to provide any start and stop bits to let the Solar reg know that a communication is about to happen? I've been reading up about RS232 and the site mentions this. Maybe the USB converter does this part and my setup doesn't?
Hope you all had great New Years celebrations.
 

Smedly

New Member
Sorry forgot to mention that I tried serout at 32 but no joy. It sends a nice clear data train but no response from the solar reg. The oscilloscope has a record function so I'll try to remember how to use it and compare the two RS232 outputs to see if there's a difference.
 

Flenser

Senior Member
Smedly,

Do I need to provide any start and stop bits
No, you do not. The hardware sending the serial adds these. If you look at the PICAXE manual you will see that the picaxe sends "Transmit serial data output (8 data bits, no parity, 1 stop bit)" when you use the serout command to send a character, It's not included in this description but here is always one start bit sent as well.

I tried serout at 32 but no joy. It sends a nice clear data train but no response from the solar reg
Checking the input to and output from the solar reg with an oscillocope is a useful test. This shows that it is the solar reg that is not responding so it looks like the solar reg is not recognizing the data being sent to it. We can focus on this and worry about any issues with the serin command after the solar reg starts responding.

What is the make and model of the serial reg?
Do you have a link to a copy of the manual?
 

Smedly

New Member
Hi Flenser.
Thanks for the info about start / stop bits. Thank goodness the Picaxe takes care of those.
Yes, you're correct about the need to get a response from the solar reg first. I've dug out the manual for the scope so will learn how to record a screen shot again.
The solar reg is a Morningstar MPPT 150V. I've got the user manual and the Modbus manual for it. The Modbus manual can be seen at http://support.morningstarcorp.com/wp-content/uploads/2014/07/MS-002582_v11.pdf

It's a well written manual that states ;

The serial communication parameters:
BPS 9600 baud
Parity none
Data bits 8
Stop bits 1 or 2
Flow control None

*The TriStar accepts either 1 or 2 stop bits. It will send 2 stop bits to provide extra byte padding. The connected PC can be set to receive either 1 or 2 stop bits.

I'm looking for the contents of register 0032 "charge state"
 

inglewoodpete

Senior Member
The TriStar says it will send 2 stop bits. This gives the PICAXE another millisecond to pack and save the character before preparing to receive the next.
 

Flenser

Senior Member
Smedly,

The connected PC can be set to receive either 1 or 2 stop bits
The picaxe serin is set to receive 1 stop bit so this is OK.

There is a known issue sending the first character when using serout with true output. This would definitely prevent the solar reg from getting the first command correctly and could be causing the solar reg reception to be "out of sync" with what the picaxe is sending.

Try the suggestion made by PhilHornby in post #7. Add the command "high C.4" to set the correct idle voltage for true output serial on pin C.4 before you send the serout command. This only needs to be done once, becuase the serout command leaves the pin high, but it won't be a problem if you put it with the rest of your high/low commands. Something like this:
Code:
Main:        pause 2000
        low C.0
        low C.1
        high C.4
        low B.0
        low B.1
        low B.2
        low B.3
        low B.4
        low B.5
        setfreq m8
        pause 200
        'serout C.4,T9600_8,($01,$03,$00,$32,$00,$01,$25,$C5)    'ask for reg charge state pin 5
        serout C.4,T9600_8,(1,3,0,50,0,1,37,197)            'pin 5
 

Smedly

New Member
I've added that in but still no reply. I'm going to try to add some scope screen shots to this message as they're quite informative. The first is the output on the USB to 232 device with the data request string 1,3,0,50,0,1,37,197. Actually typed it in in hex but you get the idea. The whole string takes 8.16uS and is about 15V peak to peak. This one works and gets an imeadiate reply from the solar reg. 1546413357760.jpeg
The second screen shot is the output of the TTL to 232 as driven by the Picaxe serout command - same data string. It takes 9.25uS and is closer to 20V P to P. This does not get a response. I tried using the calibfreq comand to speed the internal oscillator up a bit to get the same overall time scale as the data train that works but no good.
1546413468013.jpeg
The last screen shot is the same setup as number two but using the hardware serial output port on the picaxe to driver the TTL device, hserout. Much closer to the terminal generated waveform. Almost the exact same timing but still with the 20V P to P. Yet to look for a response from the solar reg as wife declared enough time spent on stupid picaxe project. Will get back to it ASAP and let you know the out come. 1546413988815.jpeg
 

darb1972

Senior Member
Agreed that the last screenshot looks almost identical to the first. Interested to see what you discover.

Yet to look for a response from the solar reg as wife declared enough time spent on stupid picaxe project. Will get back to it ASAP and let you know the out come.
I get this problem too. Yet to come up with either a hardware or software solution to this issue. The man who does will be onto a winner which will no doubt go on to be a worldwide phenomenon (good luck with that). :);)
 

hippy

Technical Support
Staff member
The first is the output on the USB to 232 device with the data request string 1,3,0,50,0,1,37,197. Actually typed it in in hex but you get the idea. The whole string takes 8.16uS and is about 15V peak to peak.
That's a typo and should be milliseconds rather than microseconds I would guess.. At 9600 baud each bit last about 104us, with 10 bits sent per byte, 8 bytes sent, that should be about 8.33ms.

That 8.16ms would be well within standard baud rate error tolerance. The time you are seeing will also be 104us or so less than it actually is if measuring from the rise of the start bit to the fall before the start of the last stop bit which will be low.

The second screen shot is the output of the TTL to 232 as driven by the Picaxe serout command - same data string. It takes 9.25uS
Note that may not mean the baud rate is incorrect. It could be that there is a larger inter-byte gap -
Code:
       _   ___       ___   _   ___       ___
1st  _| |_|   |_____|   |_| |_|   |_____|   |________
       S 0 1 2 3 4 5 6 7 P S 0 1 2 3 4 5 6 7 P

       _   ___       ___         _   ___       ___
2nd  _| |_|   |_____|   |_______| |_|   |_____|   |__
       S 0 1 2 3 4 5 6 7 P:     :S 0 1 2 3 4 5 6 7 P
                          : IBG :
It would also be in that region if using two stop bits rather than one, which would be the equivalent of introducing a bit length inter-byte gap.
 

Flenser

Senior Member
Smedly,

At this point I'm out of ideas. I've found that serial comms from a picaxe chip has always been very reliable although I have to admint that my serial comms has been mostly to and from a terminal. I'll have to give it some more thought.


Hippy,

The inter-byte gap should not matter. My understanding is that serial comms checks to see there is the right number of stop bits and then simply waits for the next start bit, no matter how much later it arrives. If there are not enough stop bits then that is a framing error but having a longer inter-byte gap is not an issue.
 

hippy

Technical Support
Staff member
The inter-byte gap should not matter.
True; I was only trying to explain one possibility for the different timings in your output, that it might not just be a baud rate or operating frequency issue.

I don't think there's much more we can do until we know if the solar reg responds to HSEROUT when it doesn't to SEROUT.

Once the solar reg is responding to the PICAXE request for data, we can see if a SERIN can read that and, if not, determine why not, and what can be done about that.
 

Flenser

Senior Member
Hippy,

I take back what I said:
The inter-byte gap should not matter.
All my experience has been doing serial between a picaxe and a terminal where the inter-byte gap has not mattered.

Smedly is doing serial between a picaxe and the solar regulator and there is a problem. I don't have any experience with modbus and there could be something about the solar regulator's serial software that means a longer than expected inter-byte gap is an issue.

Smedly,

Serout is done using bit-banged serial in software. You could try using hserout. Hserout uses the on-chip UART hardware so the character timings are likely to be tighter than with serout. The UART hardware also has a register where the next character to be sent can be loaded while the current character is being transmitted and this feature might get rid of that longer inter-byte gap.
 

Smedly

New Member
Well. After much angst and swapping everything I discovered that the picaxe chip was part of the problem. Put in a 08m2 and now I'm receiving a message back from the solar reg. BUT... with the return signal connected to the scope only it all looks good. Screen shot 1
1546494066949.jpeg
However, once I connect this wire to the TTL to 232 converter it goes to crap. Screen shot 2
1546494155468.jpeg
Looks like the source impedance of the sender is not so great. Also does the same thing when I connect it to the USB to 232 unit. Not enough signal for either converter to turn it into TTL.
Will keep trying.
 

darb1972

Senior Member
Maybe you need some sort of RS232 Line Buffer? Maybe check element14 or RS Components. Typical input impedance of an RS232 transceiver (receiver section) seems to be around 5k Ohms. Not sure why your signal is dropping? The resultant waveform tends to suggest some sort of capacitive based issue.

Just to clarify, the top screenshot is the solar reg connected to what exactly? Anything or just the scope?

How long is the cable from your project location to the solar reg? What sort of cable are you using?
 

hippy

Technical Support
Staff member
In your screen shot 2 it looks like the voltage is being halved with a short spike above half on leading edges. That to me would suggest some sort of short on the TTL-to-RS232 interface.

That is, as soon as the signal goes high, something else, perhaps the inverted signal output, goes low, and pulls the signal down.
 

AllyCat

Senior Member
Hi,

Back in #16 you talked of and showed a 20v pk-pk signal and the return signal still looks quite large. In #22 you mention a "TTL to RS232 converter" - don't you mean RS232 to TTL (as in #23) ? A "TTL" input will very probably limit to about 6v pk-pk ("protection" diodes clamping to ground and supply rail) which appears to what the 'scope shows. The overshoot might be caused by to a spike of current because the driver is designed to give a fast voltage risetime into a capacitive load.

Cheers, Alan.
 

Smedly

New Member
Maybe you need some sort of RS232 Line Buffer? Maybe check element14 or RS Components. Typical input impedance of an RS232 transceiver (receiver section) seems to be around 5k Ohms. Not sure why your signal is dropping? The resultant waveform tends to suggest some sort of capacitive based issue.

Just to clarify, the top screenshot is the solar reg connected to what exactly? Anything or just the scope?

How long is the cable from your project location to the solar reg? What sort of cable are you using?
Top screen shot is solar reg 232 output connected to scope only. Once I connect it to the MAX232 chip the signal drops down to what you see on the second screen shot. Cable is about 3ft long.
 

Smedly

New Member
In your screen shot 2 it looks like the voltage is being halved with a short spike above half on leading edges. That to me would suggest some sort of short on the TTL-to-RS232 interface.

That is, as soon as the signal goes high, something else, perhaps the inverted signal output, goes low, and pulls the signal down.
Well yes. I'm beginning to wonder if the little TTL to 232 converters that I purchased are working correctly. They seem to be a MAX232 chip on a board with female 9 pin on the top and 4 header type pins on the bottom. Bought two of these and they both do the same thing.
 

Smedly

New Member
Hi,

Back in #16 you talked of and showed a 20v pk-pk signal and the return signal still looks quite large. In #22 you mention a "TTL to RS232 converter" - don't you mean RS232 to TTL (as in #23) ? A "TTL" input will very probably limit to about 6v pk-pk ("protection" diodes clamping to ground and supply rail) which appears to what the 'scope shows. The overshoot might be caused by to a spike of current because the driver is designed to give a fast voltage risetime into a capacitive load.

Cheers, Alan.
Sorry I didn't explain that very well. The TTL to 232 converter is plugged into the breadboard and I connect to the solar reg via the 9 pin D connector on the top of the converter.
This problem is beginning to annoy me now. The solar reg also has an EIA-485 connection so I might order a TTL to 485 converter and see if that serial port works any better. Maybe the 232 port is not working as it should - although it's strange that when I connect via the USB to 232 converter and use the terminal program it all works fine. Maybe I need to hack into this system some how to allow me to hook the scope probe up and see what the signals look like in a working system.
BTW I can remove the small overshoot spikes by connecting the breadboard earth to the shell of the D connector but then I end up with a return signal that idles at about -6V and swings up to 0V. Not enough voltage swing.
 

darb1972

Senior Member
The solar reg also has an EIA-485 connection so I might order a TTL to 485 converter and see if that serial port works any better.
Smedly, I think you are on the right track and I think that's your problem right there. To the best of my knowledge RS232 and RS485 are NOT directly compatible protocols. You can get converters, but it's probably more cost effective to simply get a TTL to RS485 converter (as you suggest) for your project end.

Let us know how you go. Good luck.
 

Flenser

Senior Member
Smedly,

The solar reg manual says that it support rs232 and when you use the usb to rs232 connector it does, so it looks to me like there is something different about your setup using the ttl to rs232 converter.

You said "The TTL to 232 converter is plugged into the breadboard and I connect to the solar reg via the 9 pin D connector on the top of the converter". If the rs232 9 pin connector is plugged into the solar reg, how do you measure the rs232 voltages?
 

inglewoodpete

Senior Member
This may have been covered previously (I haven't been following all of the details of this thread) but have you got the polarity of the serial correct? The oscilloscope traces show the serial line idling low ("N") but your code in post #3 was for idle high ("T").
 

Smedly

New Member
Smedly,

The solar reg manual says that it support rs232 and when you use the usb to rs232 connector it does, so it looks to me like there is something different about your setup using the ttl to rs232 converter.

You said "The TTL to 232 converter is plugged into the breadboard and I connect to the solar reg via the 9 pin D connector on the top of the converter". If the rs232 9 pin connector is plugged into the solar reg, how do you measure the rs232 voltages?
The D connector on the TTL to 232 is female and the D connector on the solar reg is female too so when I use a standard 9 pin lead with a male on one end and a female on the other I end up with two females at the breadboard. I then jumper the leads together via wire links with the pins from a dismantled male D connector soldered to the ends. It's a bit fussy but at least I can measure what's going on.
But I've just discovered that while using the USB to 232 lead it wont work if the DTR and RTS are turned off. On the right hand side of the Serial Terminal program inside the picaxe editor.
Am I correct in assuming that turning these on causes a voltage to appear on some of the flow control pins?
 

Smedly

New Member
I feel like swearing! All it needed was +5V on pin 4 (DTR Data Terminal Ready) and away it went. The solar reg was waiting for this signal before sending a reply. It even works fine with the serin and serout commands at 16m.
I'm assuming that the signal I saw was some type of leakage from the data trx pin or maybe the reg generates the reply but the uart doesn't allow it through till receiving the DTR signal. The high imput impedance of the scope can make its display a bit misleading some times.
Thanks heaps for all your help and sugestions but in the end it was me being a dope and thinking that "no flow control" meant data only.
Might have a beer.
 

hippy

Technical Support
Staff member
I feel like swearing! All it needed was +5V on pin 4 (DTR Data Terminal Ready) and away it went. The solar reg was waiting for this signal before sending a reply.
The weird thing is, in Post #22, you indicated using an 08M2 worked, and that presumably did not have the DTR tied to 5V.
 

Smedly

New Member
The weird thing is, in Post #22, you indicated using an 08M2 worked, and that presumably did not have the DTR tied to 5V.
I could see a return signal now but as soon as I put the slightest load on it it went to crap. Even a finger on the probe tip changed the wave shape. Odd.
 
Top