serout with start bit, 8 data bits, stop bit

Bill Kingsley

Hello All. I have been trying this morning to serially control a Compact Flash digital video player, the MedeaWiz DV-66 with a BS-2. It's specs call for 4800 baud, 1 start bit, 8 data bits, 1 stop bit, at TTL levels.·I·have·not had any success. I suspect that the start bit is the trouble. The DV-66 communication·protocol can be found at http://www.teamkingsley.com/assets/userguide9-04.pdf·and the data waveform at http://www.teamkingsley.com/assets/DV66K_spec.pdf

I am trying to send data just like the above waveforms for track 1 to track 3.··I have tried to toggle the bit just before serout, tried SEROUT· 7, 16572, [noparse][[/noparse]sbit,HEX 3]··· '16572 or 188·· where sbit is a nib var set to %0 to act as a start bit, tried inverting the data, tried storing the data in a byte var as %00000010·then serout the var, tried reversing the 8 data bits (msb first, lsb first). I have a 10K pullup on pin 7, the serout pin. The DV-66 is responding to the data that I send, but it does not recognize it as a valid command and reverts to the beginning of track 1 each time I try to send a command.

I·know there is a very simple solution...I just can't yet see it. Any help would be greatly appreciated

Bill Kingsley

allanlane5

Yes, the "Start Bit" is a red-herring.

SEROUT 7, 16572, [noparse][[/noparse] 3 ] should play track three. It's the 'HEX' modifier you don't need -- that 'expands' the three into the characters "0" "3" -- when the player wants the BYTE '3'.

And if it doesn't, then SEROUT 7, 188, [noparse][[/noparse] 3 ] should work. That 'Invert' vs 'Don't Invert' is pretty tricky. Just try both.

P.S. my 'bracket' 3 'bracket' keeps getting eaten...

Jon Williams

Chris Savage and I looked at the document you reference and it seems to indicate 4800 baud, true mode (we think the "S=0" reference is a low-going start-bit; this would be True mode).· You are using inverted mode in your example.··I have this bit of code embedded in my standard template so I never have to calculate or guess baudmode parameters for "standard" baud rates:

#SELECT $STAMP
· #CASE BS2, BS2E, BS2PE
··· T1200······ CON···· 813
··· T2400······ CON···· 396
··· T4800······ CON···· 188
··· T9600······ CON···· 84
··· T19K2······ CON···· 32
··· TMidi······ CON···· 12
··· T38K4······ CON···· 6
· #CASE BS2SX, BS2P
··· T1200······ CON···· 2063
··· T2400······ CON···· 1021
··· T4800······ CON···· 500
··· T9600······ CON···· 240
··· T19K2······ CON···· 110
··· TMidi······ CON···· 60
··· T38K4······ CON···· 45
· #CASE BS2PX
··· T1200······ CON···· 3313
··· T2400······ CON···· 1646
··· T4800······ CON···· 813
··· T9600······ CON···· 396
··· T19K2······ CON···· 188
··· TMidi······ CON···· 108
··· T38K4······ CON···· 84
#ENDSELECT

SevenBit······· CON···· $2000
Inverted······· CON···· $4000
Open··········· CON···· $8000

Baud··········· CON···· T4800


I edited the Baud constant for T4800 -- copy this block and put it into your program and it should work for you, regardless of which BS2-family module you have installed.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Bill Kingsley

Thanks guys. This format "SEROUT 7, 188, [noparse][[/noparse]1] " where [noparse][[/noparse]1] is a command number from 1 to 255,·works about 70% of the time. I have·emailed the engineer at MedeaWiz to see if there is any more information they can give. The specs I have received from them so far do not show 2-way communications with the DV-66. I am wondering if it's processor is busy when I send commands or if there is some other timing issue.

Bill Kingsley

Bill Kingsley

The medeaWiz engineer has asked me if I can "increase or decrease the accuracy of the baud rate". Help me out here...4800 baud is 208.3 uS per bit. Per the Help File, INT(1,000,000 / baud rate) - 20 = 188 but would be 188.3333 before the INT(). What is the smallest increment up/down we can do with a BS-2? BS-2 SX?

Bill Kingsley

allanlane5

Well, figure out what the baud rate would be for 187, and 189. (These figures for the BS2)

187 -> 4830
188 -> 4807 Baud
189 -> 4784

So, it looks like 23 Hz per BaudModeSelect value at that frequency.

Note that 'stock' RS-232 is supposed to accept a drift of 10%, that's why we have start bits and stop bits, after all. It is supposed to 're-sync' itself on the start of each byte.

Oh, and the "works 70% of the time" bug can be caused by a poor, or missing, ground wire, connected to both sides.· Especially when it's TTL level RS-232, you MUST have a good ground wire.

Jon Williams

RS-232 comms -- especially at such a low baud rate -- is very tolerant of small bit timing inaccuracies.· If this was a real problem with the BASIC Stamp, it would have come up a lot sooner (Stamps have been around for 13 years).

Still maybe something on their end is nit-picky ... you can always tweak the baudmode value up one to see if that helps.

Theory:

187 on BS2 = 4831 baud (+0.65% error)
188 on BS2 = 4807 baud (+0.15% error)
189 on BS2 = 4784 baud (-0.33% error)

As you can see 188 is real doggone close -- close enough that it should work when the receiver is reliable.· I would bet that it is the bit timing on their end that is the problem.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Bruce Bates

Bill and Jon -

Although it won't help with bit error rates or bit timing, sometimes you can get some mileage out using data pacing to slow up the (byte) data just a little. There's certainly no harm in trying it. Data pacing can be found in the SEROUT command as a sub-parameter.

Regards,

Bruce Bates

Jon Williams

Good thought, Bruce. The receiver may be attempt to process bytes as they come in.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Jeff Martin

Hi,

I'm coming in late in this conversation and don't have time to read it all (someone clued me into this thread) but thought of posing the following questions:

1) Have you ever tried it without the 10K pullup resistor on SOUT?· I'm not sure why you have it there, but most connections don't require an external pullup resistor because the receiving device itself should have one already (else it would receive garbage all the time when nothing is connected).

2) Are you sure that you need to send a 1?· I mean a binary 1?· Perhaps the docs are really suggestion an ASCII 1, ie: "1" which is decimal 49.

Hope this is of some help.

--Jeff

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.

allanlane5

Nope, Jeff, you can read the reference he gave -- it's pretty clear that it wants a CHAR(1), not a string "1". And he says that works for him.

Hmm. If he really does have a 10K pull-up in there, maybe he does need one of the 'open' modes. Or he shouldn't have the 10K pull-up in there. Which "Vdd" is the 10K tied to? I'm still betting on either bad grounding, or trying to send TTL RS-232 too far (10 feet might be too far). How far away is the BS2 from the device it's trying to control?

Bill Kingsley

I have been using the BS2 to serially communicate with a wide variety of devices for at least 10 years and have never had this much trouble. Slowing the baud has helped. I have tried 187 to 193 so far...187 is worse...the slower ones are better but have not had enough time to watch the changes (on the videos playing) to come to a conclusion as to which slower baud works best. It appears to respond correctly about 90+% of the time now at 191. We are using a pullup to the BS2 power. MedeaWiz also sells a keypad accessory, the DV-66K, which is powered by the DV-66 and sends serial commands to the DV-66. It has a pullup onboard for the TX line. Comm. from it to the DV-66 has worked every time. It is using a Winbond W78LE52P-24 micro. The crystal is 7.3728 Mhz. Specs for the Winbond micro say that internally crystal freq. is divided by 2. So it would appear that the micro runs at 3.6864 Mhz. Does anyone know what the ACTUAL baud rate would be for this micro at 4800? The length of the MedeaWiz supplied standard RJ-11 serial cable is 6 feet and it works fine with the DV-66K. I have it connected to the BS2 on a proto-board via a new gold plated RJ-11 jack. My client/ friend is getting similar results on his bench with the same set-up. I do not think the pace modifier is appropriate here since we only send 1 byte per command. I do not know if the DV-66 is ready at all instants to receive a command. I assume it is quite busy since it plays MPEG 2 video at 5 Mbps from a Compact Flash card. My contact at MedeaWiz said that there is not 2 way comm at this time. I have a few more things to try and will post the results.

Larry~

Do you have a scope
I know you said TTL levels but could a line driver be the differance
check to see if the command is sent twice or just try it

Bill Kingsley

I have only an old analog scope. Not sure I would be able to see much on it. I have slowed the baud to near 4700 and am sending each command 4 times. It has been running a ~1 minute loop with 5 commands for an hour now and has not missed a command so far.

'Serial comm test for MedeaWiz DV-66 digital video player using
'Parallax Basic Stamp model BS2
'Beta Version, not for distribution
'6/22/05 Team Kingsley LLC
'www.teamkingsley.com


'{$STAMP BS2}

'187 on BS2 = 4831 baud (+0.65% error)
'188 on BS2 = 4807 baud (+0.15% error)
'189 on BS2 = 4784 baud (-0.33% error)
'190 on BS2 = 4761 baud (-0.81% error)
'191 on BS2 = 4739 baud
'192 on BS2 = 4716 baud
'193 on BS2 = 4694 baud
'we have not yet determined the optimal "actual baud rate"
'however this code works very well...
Top:

SEROUT 7, 193, [noparse][[/noparse]1,1,1,1] 'using I/O 7 to xmit to DV-66
'send byte 4 times
PAUSE 5 'wait a few Ms before debug out
DEBUG CLS, "Track 1" 'show track number on PC screen

PAUSE 15000 'play track for 15 seconds

SEROUT 7, 193, [noparse][[/noparse]2,2,2,2] 'using I/O 7 to xmit to DV-66
'send byte 4 times
PAUSE 5 'wait a few Ms before debug out
DEBUG CLS, "Track 2" 'show track number on PC screen

PAUSE 15000 'play track for 15 seconds

SEROUT 7, 193, [noparse][[/noparse]3,3,3,3] 'using I/O 7 to xmit to DV-66
'send byte 4 times
PAUSE 5 'wait a few Ms before debug out
DEBUG CLS, "Track 3" 'show track number on PC screen

PAUSE 8000 'play track for 8 seconds

SEROUT 7, 193, [noparse][[/noparse]246,246,246,246] 'pause 'send byte 4 times

PAUSE 5000 'still-frame for 5 seconds
SEROUT 7, 193, [noparse][[/noparse]247,247,247,247] 'play 'send byte 4 times

PAUSE 5000 'continue play for 5 seconds

GOTO top 'go to top and do it all again

END

Jon Williams

So is it the redundant commands or the baud rate (that, by the way, is way off the vendor's spec)?

Note that you could edit you code more easily by using named constants instead of embedded values.· For example:


TX·······PIN··· 7
·
Baud···· CON··· 193

cmd····· VAR··· Byte
delay··· VAR··· Word
idx······VAR··· Nib
·

Main:
· FOR idx = 0 TO 4
··· LOOKUP idx, [noparse][[/noparse]1, 2, 3, 246, 247], cmd
··· LOOKUP idx, [noparse][[/noparse]15, 15, 8, 8, 5], delay
··· delay = delay * 1000
··· GOSUB Send_Cmd
··· PAUSE delay···
· NEXT
· GOTO Main
·
·
Send_Cmd:
· SEROUT TX, Baud, [noparse][[/noparse]cmd, cmd, cmd, cmd]
· RETURN


I know you're just testing things at the moment, but I'm a very big believer that test code can be ported to production code and save a lot of rework -- it just takes a little planning.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax