If you have one of those VEX Transmitter/Receiver kits this thread will show you how to connect the transmitter (directly) or receiver to the Prop-SX in order to drive four servos with the joysticks (the program presented ignores channels 5 and 6). At the request of one of our friends this program also dumps the servo position values to a PC using the DB-9 connector on the Prop-SX.
Step 1 :: Build a cable
This is the trickiest part. The connectors on the VEX transmitter and receiver are narrow so you'll need a telephone headset extension (a regular phone extension won't work). Cut this cable in half and splice it to servo extension cable. Note that the diagram shows the socket -- you'll need to check your cable as it would be plugged into this port for corresponding wire colors (this depends on which end of the cable you use).
(http://www.efx-tek.com/files/vex_to_prop-sx.png)
Step 2 :: Program the Prop-SX
Okay, this is the easy part. Download the following program to your Prop-SX. Note that P15 must have the ULN removed (either replace with a ULN2003 or clip pin 1 of the ULN2803), and move the P15 SETUP jumper to UP. Plug your servos into P0-P3 and let 'er rip. Note that you can change the baud rate setting to the PC to any value that the resonator you're using (I've got mine set for 20 MHz) will support. The SX/B compiler will warn you if the specified FREQ will not support the desired baud rate.
Note: A resonator MUST be installed for serial communications to the PC (the internal oscillator is not accurate enough).
Minor updates to program: 24 JUN 2008
' =========================================================================
'
' File...... VEX_Servos_EZ.SXB
' Purpose...
' Author.... Jon Williams, EFX-TEK
' Copyright (c) 2008 EFX-TEK
' Some Rights Reserved
' -- see http://creativecommons.org/licenses/by/3.0/
' E-mail.... jwilliams@efx-tek.com
' Started...
' Updated... 24 JUN 2008
'
' =========================================================================
' -------------------------------------------------------------------------
' Program Description
' -------------------------------------------------------------------------
'
' Note: Resonator must be installed for serial communications to PC
' -------------------------------------------------------------------------
' Conditional Compilation Symbols
' -------------------------------------------------------------------------
' -------------------------------------------------------------------------
' Device Settings
' -------------------------------------------------------------------------
DEVICE SX28, OSCXT2, TURBO, STACKX, OPTIONX, BOR42
FREQ 20_000_000
ID "VexServo"
' -------------------------------------------------------------------------
' I/O Pins
' -------------------------------------------------------------------------
VexIn PIN RC.7 INPUT ' P15, SETUP = UP, no ULN
ServoCtrl PIN RB ' servo control pins
Servo3 PIN RB.3 OUTPUT
Servo2 PIN RB.2 OUTPUT
Servo1 PIN RB.1 OUTPUT
Servo0 PIN RB.0 OUTPUT
TX PIN RA.3 OUTPUT ' to PC
' -------------------------------------------------------------------------
' Constants
' -------------------------------------------------------------------------
IsOn CON 1
IsOff CON 0
Yes CON 1
No CON 0
Baud CON "T57600"
' -------------------------------------------------------------------------
' Variables
' -------------------------------------------------------------------------
flags VAR Byte
tix VAR Word ' for counting timing cycles
idx VAR Byte ' loop index
tmpB1 VAR Byte ' for subs/funcs
tmpB2 VAR Byte
tmpW1 VAR Word
tmpW2 VAR Word
svoData VAR Byte (4) ' bank servo data
pos VAR svoData(0) ' position table
pos0 VAR svoData(0)
pos1 VAR svoData(1)
pos2 VAR svoData(2)
pos3 VAR svoData(3)
' =========================================================================
' INTERRUPT
' =========================================================================
' RETURNINT
' =========================================================================
PROGRAM Start
' =========================================================================
' -------------------------------------------------------------------------
' Subroutine / Function Declarations
' -------------------------------------------------------------------------
DELAY_US SUB 1, 2 ' replaces PAUSEUS
DELAY_MS SUB 1, 2 ' replaces PAUSE
TX_BYTE SUB 1 ' transmit a byte
TX_STR SUB 2 ' transmit a string
' -------------------------------------------------------------------------
' Program Code
' -------------------------------------------------------------------------
Start:
PLP_A = %1000 ' pull-up unused pins
PLP_B = %00001111
PLP_C = %10000000
TX = 1 ' tx to idle
DELAY_MS 10 ' let receiver clear
TX_STR ID_Tag
Main:
tix = 0
DO WHILE tix < 300 ' wait for sync pulse
IF VexIn = 0 THEN
INC tix
PAUSEUS 10
ELSE
tix = 0
ENDIF
LOOP
Release_Sync:
DO WHILE VexIn = 0 ' wait for end of sync
LOOP
Get_Servos:
ServoCtrl = %0000_0001 ' start servos
FOR idx = 0 TO 3 ' loop through four servos
tix = 0 ' clear counter
DO WHILE VexIn = 1 ' hold for framing pulse
LOOP
DO
PAUSEUS 10
INC tix_LSB ' update timing count
LOOP UNTIL VexIn = 1 ' until pulse finished
pos(idx) = tix_LSB + 50 ' update postion (add framing)
ServoCtrl = ServoCtrl << 1 ' next serov
ServoCtrl.4 = 0 ' limit to four servos
NEXT
Update_PC:
TX_BYTE $FF
TX_BYTE pos0
TX_BYTE pos1
TX_BYTE pos2
TX_BYTE pos3
GOTO Main
' -------------------------------------------------------------------------
' Subroutine / Function Code
' -------------------------------------------------------------------------
' Use: DELAY_US duration
' -- duration is in microseconds
' -- replacement for PAUSE
SUB DELAY_US
IF __paramcnt = 1 THEN ' byte value passed
tmpW1 = __param1
ELSE ' word value passed
tmpW1 = __wparam12
ENDIF
PAUSEUS tmpW1
ENDSUB
' -------------------------------------------------------------------------
' Use: DELAY_MS duration
' -- duration is in milliseconds
' -- replacement for PAUSE
SUB DELAY_MS
IF __paramcnt = 1 THEN ' byte value passed
tmpW1 = __param1
ELSE ' word value passed
tmpW1 = __wparam12
ENDIF
PAUSE tmpW1
ENDSUB
' -------------------------------------------------------------------------
' Use: TX_BYTE aByte
SUB TX_BYTE
SEROUT TX, Baud, __param1
ENDSUB
' -------------------------------------------------------------------------
' Use: TX_STR [String | Label]
' -- pass embedded string or DATA label
SUB TX_STR
tmpW1 = __wparam12 ' get address
DO
READINC tmpW1, tmpB1 ' read a character
IF tmpB1 = 0 THEN EXIT ' if 0, string complete
TX_BYTE tmpB1 ' send the byte
LOOP
ENDSUB
' -------------------------------------------------------------------------
' -------------------------------------------------------------------------
' -------------------------------------------------------------------------
' User Data
' -------------------------------------------------------------------------
ID_Tag:
DATA "VEX Decoder", 13, 10, 0
Just a follow-up on this: I put a scope on the VEX output and found that each servo frame is every 18.5 milliseconds; this matters if you're taking the data to be exported to another program, or recording it to playback later (as I'm doing with a VEX/Prop-SX/Waldo project).
This works GREAT! I was able to animate my 3-axis skull with the VEX transmitter cabled to a Prop-SX.
I am able to capture the data that is being sent out the serial port on the SX. I have the 50hz resinator installed.
The code has baud set to T57600 so I am trying it at that speed. I need to do some evaluation of the data and see if we can put it in some normalized format. I will let you know.
Jeff
That's great news, Jeff. It will be really cool if there is a way for you to capture the data and export it for programs like VSA and Vixen -- I'm sure a lot of folks would enjoy that.
Ok, on first inspection we are going to need a little change in your program. We need to send some sort of sync byte. since you are sending the 4 bytes that represent the state of the 4 servos lets send a byte or two after that that we can use as a separator and also a sync byte so if we loose data (which is what I am seeing now) we can get back on track. I can work on speeding up the capture side but it would be nice to identify the packets easier. If the valid range for pos(idx) is 0-255 then maybe we send 00 as a header?
What would you suggest?
Jeff
Never mind. I see the &FF in the code. Let me work with the capture a bit more and see if I can clean up the data loss first. I am seeing a lot of missing FF's that should be there.
Jeff
Jeff,
You should see position values of 100 to 200 (plus/minus a bit) so $FF is used for sync -- this value would never show up as a servo position.
I have a couple of questions.
I see that you set the Baud rate to 57600?
Baud CON "T57600"
Are you just wanting to be as fast as possible?
Just to make sure the sync byte $FF you are sending is a value of 255 correct?
So far all my tests are showing a LOT of dropped data. I often see less than 3 values between the 255 sync bytes or a bunch of bytes (12 or more) before the next sync byte.
Lastly, if I run the program on the Prop-SX for a while it eventually just hangs and no longer talks to the servos. I reset the board and everything is fine. It seems to happen more often when I am moving the servos a lot. Any ideas?
Jeff
Yes on the baud rate and sync values. There's actually a fair bit of time after the last servo pulse so you could drop the baud rate if you think that will help. Since the sync pulse detect section is looking for a 3 ms low, you have about 5 milliseconds to send your data. At 19.2K you can get everything out in 2.6 ms -- this is about as low as I'd go.
I've never seen the SX program hang, and I've left it running on my bench overnight more than once. Unfortunately, I forgot to bring my VEX transmitter to MHC, so I won't be able to experiment until next week (in between trips). I'll try to write a little VB program that receives the packets and indicates possible errors.
I'm not sure what could be happening on the SX side as this is a butt-simple program, and relies on the VEX transmitter for timing.
The hanging doesn't happen all the time. And it only seems to happen when moving the servos with the vex so letting it run overnight would probably work. Just like you I don't know what could be happening in the code but you can tell when the servos stop being serviced.
There are a lot of options with the VB Serial Code. Can you shed a little light on what the Prop-SX serial port expects? Things like DTS, RTS, Flow Control. Are we connecting at 8-N-1? Any other details?
Jeff
The program doesn't know or not if the joysticks are moving because it's simply measuring pulses and sending those values -- unless the VEX output is doing something weird that is being masked by the slowness of the servo movement. I'll connect it to a scope and watch while moving the joysticks. I may have to trigger the scope with the SX to sync with the frame as the frame rate of the output doesn't match a standard o-scope timebase.
The serial is straight 8N1 -- no magic, especially if you're just receiving data from the board. If you're transmitting to it you have to filter anything you send from your input buffer (legacy issue from the Prop-2 board [which uses the same PCB layout] that we will remove in the next version of the Prop-SX).
How are you parsing the data from your buffer? I would do this:
-- look for $FF in the stream
-- grab the four bytes that follow
-- are any of these four bytes $FF?
-- if yes, there is a frame error and I would duplicate the previous packet to the output data
-- I would attempt to re-align on the new $FF
-- is the next byte in the stream $FF
-- if no, there is a frame error... not sure what I'd do about this one
Each packet of five bytes comes in every 18.5 milliseconds or so -- should be plenty of time for a PC to deal with it. That said, the PC programming that I do tends to be very simple and capturing a bunch of data like this is something I haven't done.
Thanks for all the quick responses. I know you are at MHC and busy this weekend so I didn't expect too much of a response.
I'll see if I can figure out a patern on the hanging. It is so random though. I can go for quite a while where it doesn't do it at all. Would the fact that I am using the teather port in the back of the VEX instead of using the reciever matter?
All my data capture tests have been straight dumps of the recieve buffer to a file. I am then parsing the file to find the packets. Based on what I am seeing so far if I follow your parsing logic on the recieve buffer I'd throw away almost all the data. There seems to be very few packets with a $FF and 4 valid bytes. But now that I think of it maybe that is the problem. I might be thinking there is more data than there really is and the rest is just noise? I'll take a closer look.
All my serial experience on the PC has been mostly modem communications and talking to hardward devices that have some sort of ACK/NAK protocol like credit card processing. I haven't done any real time high speed data collection.
Jeff
Jon-
I don' think this is a big deal but is this a typo in your program?:
svoData VAR Byte (4) ' bank servo data
pos VAR svoData(0) ' position table
pos0 VAR svoData(0)
pos1 VAR svoData(1)
pos2 VAR svoData(2)
pos3 VAR svoData(3)
You've got two svoData(0) zero's there, I think there should just be one?
EDIT:Looking at some of your other Prop-sx programs, it appears you do this quite frequently so, Nevermind! :)
It is deliberate, Shawn, and here's why: You could access each position value individually...
pos0 = 150
pos1 = 150
pos2 = 150
pos3 = 150
... or you could access them in a loop:
FOR idx = 0 TO 3
pos(idx) = 150
NEXT
Aliasing different names to the same location is a frequent trick.
Quote from: davisgraveyard on June 10, 2008, 06:59:32 PM
This works GREAT! I was able to animate my 3-axis skull with the VEX transmitter cabled to a Prop-SX.
I am able to capture the data that is being sent out the serial port on the SX. I have the 50hz resinator installed.
The code has baud set to T57600 so I am trying it at that speed. I need to do some evaluation of the data and see if we can put it in some normalized format. I will let you know.
Jeff
Jeff, did you use the VEX that we got at the RMG?
Technically no. I have 3 Vex transmitters. 2 I borrowed from a friend. The third I got from RMG with the intention of giving back the others to my friend. But when I did the testing since the RMG one didn't come with a charged battery and my friend had a couple of charged battery packs I used his. I am pretty sure that the other one will work fine though.
Jeff
Jon, I never did get anywhere on capturing data out the serial port. All I seem to get is garbage. Could you test it on your end and make sure you are just seeing groups of 5 bytes? I will do more testing on my end if you confirm that it is working as it should. I am setting my COM port to 57600 baud 8-n-1 no flow control. It doesn't even look right in hyperterm. Still seeing random noise.
Jeff
Sure. I'm in Arizona this week as a guest at the University of Advancing Technology, and I don't have my VEX package with me. While I'm here I'll see if I can whip up a VB program to receive the data and report any packet errors.
You don't even need to write a VB Program just use hyperterm to connect to the RS-232 port on the board. You can capture the data to a file. You should see a 5 byte character pattern if you just let the servos idle. The first byte should always be the same (FF). I'm not seeing this. In my case the data is just noise with little or no pattern.
I was wondering. In the code you posted at the begining of this thread is there a way to smooth out the servo movement a bit? I am looking at the code and am not sure what would need to change to do this? Is this even possible?
Jeff
You could take multiple samples and then average them, but then you would lose your change resolution. If, however, you just wanted to record servo positions every 100 ms, you could take samples and average them -- this would smooth the movement within that period.
Jeff,
I'm going to blame the "garbage" you captured as something on your end -- probably HyperTerminal. I pumped data into HT but used another program, Free Serial Port Monitor, to capture the data. Here's the dump (note that I added a text header at the beginning because HT doesn't like non-ASCII characters):
Port opened by process "hypertrm.exe" (PID: 540)
56 45 58 20 4D 6F 6E 69 74 6F 72 0D 0A FF A9 B1 VEX Monitor..ÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 ±›šÿ©±›šÿ©±›šÿ©±
9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B ›šÿ©±›šÿ©±›šÿ©±›
9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A šÿ©±›šÿ©±›šÿ©±›š
FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF ÿ©±›šÿ©±›šÿ©±›šÿ
A9 B1 9B 9A FF A9 B1 9B 9A FF A9 B1 9B 9A FF A9 ©±›šÿ©±›šÿ©±›šÿ©
B1 9B 9A ±›š
After a few minutes I just turned off the Prop-SX. If you look closely, from the first FF until the last packet, everything is correct. Don't worry about the values -- I was tweaking the adjustments on the VEX transmitter.
Now that I'm satisfied I'll see if I can come up with a VB capture program. No promises, though, I'm better at the SX than with VB.
OK I guess you proved that it works. I have a guess what it might be on my end. I am using the Parallax USB to serial adaptor to test this with? My development computer and my laptop don't have 9 pin serial ports just USB ports. If this isn't the problem then I would guess that my serial port config for capturing must be setup wrong. I am using 57600 baud 8 data bits no parity and 1 stop bit (8N1). I set the port to no flow control.
Here is the little VB program I am using. I use the MS Comm control for serial IO. It is currently set to COM3. It captures serial data to a file c:\data.dat and then can process the data to a file c:\data.txt .
http://www.davisgraveyard.com/PropSX-Vex.zip (http://www.davisgraveyard.com/PropSX-Vex.zip)
Let me know if it is working for you. If so then it MUST be my USB connection?
I'm certain that it's NOT the USB connection. I also tested at 57600 with no problems. Yes, I did modify the program a little bit, but only to improve the accuracy of pulse timing; nothing to do with serial comms (update posted in top of this thread).
I'm on my way out for a few hours; will look at your VB program when I return.
Just tried the new version of the program. The serial capture is working fine now. Hum.....you SURE you didn't change any of ther serial stuff?
One thing I am noticing though. The program haulting is happening more often. It seems to happen whenever the servo has any strain or has trouble holding its position. Like the jaw movement (weight of jaw) or my tilt which binds a bit when in the extream settings. Doesn't seem that noticable when running.
The controller just stops and I have to push reset to get it going again?
Jeff
You may be causing the board to brownout with servos drawing a ton of current when stalled -- servos can get rough this way. Change BOR42 in the DEVICE line to BOR26, this will reduce the brownout threshold and may help out. If possible, don't let the servos stall or bind because they can draw a lot of current when this happens. In the worst case condition you may have to power the servos from a separate supply.
Thanks that did seem to help a little. I still saw a couple of halts but after a while things seem to be moving smoothly. I am not seeing much strain on the servos they seem to be moving freely. But I guess that was it?
I wanted to clarify where we are going with this serial interface to the PC and the captured data. Our goal, if I understand it, is to create statements like this
DATA 150, 150, 150, 150, 0
The idea being that we can eliminated the duplicate values and combine them into 1 statement with a timing value for each 20ms duplicate right?
so each 4 values represents a 20ms setting for the servos. Do we only use a value of 0 for the timing on the last entry or am I not understanding how the 0 value works?
Jeff
I'm not going any particular direction with this stuff; I've done it purely as a service to our customers that have asked for the ability to record the servo data provided by the VEX interface.
Now... if one can capture the data then the easiest way to conserve space in the SX is to use some sort of compression. I do this by using the fifth element of that DATA line as a count for the number of servo periods (typically, 20ms) at the positions stated by the first four elements. In the SX I would use a zero timing value as the end-of-sequence indicator.
In code a servo engine might look like this (assuming background servo processing in place):
Run_Servos:
addr = Show_Label
DO
READINC addr, pos0, pos1, pos2, pos3, timing
IF timing = 0 THEN EXIT
DO WHILE timing > 0
DELAY_MS 20
DEC timing
LOOP
LOOP
In this example pos0 - pos3 are the registers used by the background servo processor.
Just roughly, how many DATA lines do you think would be a reasonable limit given enough space for code?
I have cleaned up my Vex Data capture program. www.davisgraveyard.com/PropSX-Vex.zip (http://www.davisgraveyard.com/PropSX-Vex.zip)
This will capture data from the Vex to a file. It will process the file and create a text file that contains all unique DATA statements.
I'm wasn't quite sure on the timing value count. If there is only one of the 4 values is the timing value 0? If there are 2 sets of the same values is the timing value 1 or 2? Also are we getting VEX data sent to us faster than 20ms or is each 4 value block a 20ms setting?
Here is a zip of the capture file and the processed text file. www.davisgraveyard.com/capture.zip (http://www.davisgraveyard.com/capture.zip)
Jeff
Use zero to exit the servo data processing, any no-zero value to hold at the stated positions. The final record will probably be manually coded so that you can set the "resting" positions of the servos.
Here is a video of the Prop-SX program in action.
http://www.youtube.com/watch?v=idUfOeE9Gx0 (http://www.youtube.com/watch?v=idUfOeE9Gx0)
I am finally getting back to this project. I made a HUGE discovery yesterday that I think will make this work SO much better. I was trying to capture jaw movements while playing audio and storing the data to a text file. I was having trouble with the Prop-SX code failing in the middle of the routine (had to reset to keep going). And I wasn't happy with my jaw sync movements using the VEX. So I hooked up a cowlicous audio controller to the jaw servo to see how it would look with the audio (wanted some sort of reference). By gosh it looked great! So while the audio boad was moving the jaw I started moving the VEX using the Prop-SX for the head turn, nod, and tilt. There are a LOT less movemnents for those movements than the jaw.
So I'm thinking of just going back to a Prop-2 for the show. But I am going to use the Prop-SX w/ VEX to capture the head movements. Then in the Prop-2 I am going to fire off the UMP3 player while will have its output split to the Cowlicious audio board and to the speakers. I'll play the head movement data through the Prop2 since it isn't that much data. The rest of the show which is just LED fades and triggers is all sequencial so nothing is happening at the same time anyway.
I REALLY like the idea of using an audio controller for the jaw movement along with the Prop-2 or SX for subtle head movement. Having the dedicated jaw movement frees up a lot of resources and it looks so much better.
Jeff
At the risk of sounding defensive, I have trouble with the phrase "Prop-SX code failing" -- I've run that code through the ringer and it doesn't fail, and I've done lots of data captures on the serial output and it is always correct.
I believe there is something in your electrical circuit that is wreaking havoc with the controller; my guess is that your servos are overloading the electrics and causing the Prop-SX to hang -- I think this can be corrected by using an external supply for the servos. You could make a power supply adapter for the Prop-SX using a Proto PCB.
That said, if an audio follower works by all means use it. I've been wanting to experiment with one of those circuits, but time is just not on my side at the moment.
Ok "Prop-SX code failing" was a poor description of the problem. The issue I think is what you described. You called it "brownout" in a previous post and suggested changing the BOR42 to BOR26 in the DEVICE section to reduce the brownout threshhold. That didn't seem to help. Just to repeat the behaviour is that I start using the Prop-SX and the VEX to move the servos and randomly (sometimes right away sometimes after a short while) the program just shuts down and all the servos go dead. I have to press the reset button to get control again. None of the servos are binding and are able to move freely without much resistance. I am using a 12VDC 200ma power supply to run the 4 servos. I have also disconnected the Jaw servo (which had the most strain) and the same thing still happens.
One observation I noticed. When I started using the audio servo driver board for the jaw movement I noticed that the board moved the servo with a LOT more force. When using the VEX with the PROP-SX the jaw movement was slower and had less torque. I didn't notice it until I used the other board and watched how it threw the servo all over the place with MUCH more force than the Prop-SX ever did? Granted I am using a separate 6v power supply for the board to drive the single server and maybe that is what you are suggesting about using a separate power supply for the servos?
I appologize if I indicated that the program you wrote in any way was faulty. That is not what I was trying to say. I just wanted to point out that all the programmed data required to drive jaw movements could be saved by using an audio servo driver board instead. Using the VEX and Prop-SX works great to puppeteer the head without having to worry about the jaw movements. It is also a LOT less of a syncing issue since the had turn, nod,tilt can start and stop just about anywhere in the speach and still look good.
Jeff
For what its worth:
200 mA is REALLY low for 4 servos. That would be a max of 50 ma each during movement, and I really think that is too small for a servo.
Also, are you powering your Prop-SX off that as well or do you have a seperate supply?
I suspected that was the issue when I posted my msg saying I was using 200ma supply. I grabbed a 1.5a 12VDC adaptor and tried it. And low and behold no brownout? And the servos have a lot more life to them like the audio board does. And Yes I am powering the Prop-SX and the 4 servos with the supply.
Doug, what do you think about the combo audio talker board and Prop-2 for head movement? Have you tried that?
Jeff
On the apparent torque improvement using the audio talker: what you may be seeing is a quicker [direct] jump between one value and another, whereas with the VEX you're moving a joystick through a set of values -- instead of jumping directly from one to another -- so the response seems slower.
I am trying to convert the data coming out of serial port on the Prop-SX when hooked to the VEX running Jon's program to DATA statements that the Prop-2 can understand.
I am getting values like 165,161,162 etc from the Prop-SX. My little VB app reads the data from the RS-232 and dumps it to a binary file. I then have another step in the program that can convert the binary file to a text file formated like this DATA value1,value2,value3,value4,timer where timer is the number of times the 4 values stay the same.
But I seem to recall that the values for the Prop-2 for servo movements are different? Am I wrong? What would I need to change in my text file to use these DATA statements in a Prop-2 servo player?
Jeff
One other problem. The data that I have captured from puppeteering the head for a 2min speech is about 79K. I didn't move the head around that much during the speach. Most of the entries have a timing value of 1 where only one of the 3 servos (nod,tilt,turn) changed 1 value like this...
DATA 165,161,162,3
DATA 166,161,162,2
DATA 168,161,162,1
DATA 170,161,162,1
DATA 171,161,162,1
DATA 172,161,162,1
DATA 174,161,162,1
DATA 176,161,162,1
DATA 179,161,162,1
DATA 181,161,162,4
DATA 182,161,162,1
DATA 185,161,162,1
DATA 188,161,162,1
DATA 190,161,162,1
DATA 191,161,162,4
DATA 192,161,162,1
DATA 194,161,162,5
There are over 4000 lines like this and it is going to be too much to use in a Prop-2 Program? Any ideas on how I could condense the data down?
Jeff
You could use an simple RLE scheme, but I think implementing that would be more trouble than it's worth, and you may end up with less show space in the EEPROM anyway. But let's say you want to give it a go... instead of using four bytes every 20 milliseconds, you could collapse redundant records by using five bytes, the fifth being how many 20 millisecond cycles to hold those values.
The problem with this scheme is that any changes from one record to another force a new record; you might want to use a PC to filter the data so that very small changes are cleaned up. Noise in the system will cause small changes that will defeat your compression scheme.
By my calculation you can fit about 2 minutes of "show" into the EEPROM without compression. Is this not enough?
32 x 1024 = 32,768; 32,768 / 4 = 8,192; 8,192 x 0.02 = 163.8 seconds.
One of the things I am doing is only using 3 servos for the show even though the Vex program controls 4. The 4th is for the jaw. My PC program compresses the raw captured data by only recording changes in the 3 servos and compressing duplicates into a single DATA line and increasing the timer. That said the data I captured while puppeteering for 2 minutes after compressing generated 4000+ lines and is 79K. When I try to paste that into my Prop-2 code and load it it says the program is over 64k and won't load.
I could try to be a little more subtle about my movements and hold the joysticks a little more still so there isn't a constant change going on. That should reduce the data?
Not sure how you are coming up with your "show" calculation?
Jeff
I still think think that noise in the system will be problematic with subtle movements.
My "show" calculation:
A) The Prop-SX has a 32K byte EEPROM (32 x 1024 = 32768 bytes)
B) Controlling four servos you can squeeze 8192 records into the EEPROM
C) If each record runs for 0.02 seconds the total time is 163.8 seconds (2:43)
If you knock that down to three servos you get 218.4 seconds (3:38)
Yes but I am trying to do this with a Prop-2. Capture the data with Prop-SX but store the show in a Prop-2? Do I not have enough room?
I was also asking how to convert the data for the Prop-2? The values for the Prop-SX / VEX program are 100-200. But isn't the range for the Prop-2 higher? What is the conversion?
Jeff
Sorry, I misunderstood. No way, no how, no can do, Buckaroo! I have some servo compression code posted here in the forums but you're going to be seriously limited as to the amount of "show" you can squeeze into a 2K EEPROM that is also holding your program.
[Edit] I found one of those programs an bashed it up to work with an external device (STAP) and three servos; the length of your show will depend on the changes in your moves.
' =========================================================================
'
' File...... Servo_Blender-3x.BS2
' Purpose...
' Author.... Jon Williams, EFX-TEK
' E-mail.... jwilliams@efx-tek.com
' Started...
' Updated... 02 SEP 2008
'
' {$STAMP BS2}
' {$PBASIC 2.5}
'
' =========================================================================
' -----[ Program Description ]---------------------------------------------
' -----[ Revision History ]------------------------------------------------
' -----[ I/O Definitions ]-------------------------------------------------
AudioStart PIN 15 ' pulsed audio start
Trigger PIN 14 ' trigger input
Servo3 PIN 10
Servo2 PIN 9
Servo1 PIN 8
' -----[ Constants ]-------------------------------------------------------
IsOn CON 1
IsOff CON 0
RecLen CON 4 ' record length (servos + 1)
EOS CON $FF ' end of show marker
' -----[ Variables ]-------------------------------------------------------
timer VAR Byte ' for trigger debouncing
record VAR Word ' movement record
pntr VAR Word ' table byte pointer
s1Pos VAR Byte ' servo 1 position
s2Pos VAR Byte ' servo 2 position
s3Pos VAR Byte ' servo 3 position
repeats VAR Byte ' repeats for record data
' -----[ Initialization ]--------------------------------------------------
Reset:
OUTH = %00000000
DIRH = %10000111 ' set outputs
record = 0 ' point to home positions
GOSUB Get_Servo_Pos
' -----[ Program Code ]----------------------------------------------------
Main:
timer = 0
DO WHILE (timer < 200)
GOSUB Refresh_Servos
timer = timer + 20 * Trigger ' debounce trigger
LOOP
Start_Audio:
AudioStart = IsOn ' "blip" audio output
GOSUB Refresh_Servos
AudioStart = IsOff
Move_Engine:
record = 1 ' start of moves
DO
GOSUB Get_Servo_Pos
IF (s1Pos = EOS) THEN EXIT ' abort if at end
DO WHILE (repeats > 0) ' count down repeats
GOSUB Refresh_Servos
repeats = repeats - 1
LOOP
record = record + 1 ' point to next record
LOOP
GOTO Reset
' -----[ Subroutines ]-----------------------------------------------------
' Call with "record" set to table line to read
Get_Servo_Pos:
pntr = record * RecLen
READ (Moves + pntr), s1Pos, s2Pos, s1Pos, repeats
RETURN
' -------------------------------------------------------------------------
' Update servos -- time consumed is 18 to 21 ms
Refresh_Servos:
PULSOUT Servo1, s1Pos * 5
PULSOUT Servo2, s2Pos * 5
PULSOUT Servo3, s3Pos * 5
PAUSE 15 ' pad for loop timing
RETURN
' -----[ EEPROM Data ]-----------------------------------------------------
' Note on servo movement timing:
'
' Time spent on each record is ~20 ms x (repeats + 1) so a repeats value
' of 0 is ~20 ms and a repeats value of 255 (max) is ~5.1 seconds at
' that position.
'
' s1 s2 s3 rpts
Moves DATA 150, 150, 150, 1 ' home positions
DATA 150, 150, 150, 1 ' start of moves
DATA 150, 150, 150, 1
DATA 150, 150, 150, 1
DATA 150, 150, 150, 1
DATA EOS, EOS, EOS, 0 ' end of show
Funny you should post this right after I just came to the realization that this isn't going to work on a Prop-2. I was able to cram about 395 of the 1097 data lines. That 1097 was compressed down from the 3000 lines where only 1 servo changed 1 value. You are right No-way-no-how.
I only thought about using the Prop-2 since I was going to use an external board for moving the jaw which generated most of the data to begin with. But even gently moving the head creates too much data for the Prop-2.
I grabbed the same program you just posted to try it but can't get the data into the 2k EPROM. So I am back to using the Prop-SX which isn't that big of a deal but I have to keep flashing the program to go from recording to playing. I'll let you know how it goes.
Jeff
You realize you can't "flash" data into the external EEPROM of the SX, right? Now, if you've written a program that copies DATA statements to the EEPROM, you're cool.
[Edit] I take it back, a program to move DATA statements to the EE is pretty useless as there is only 2K of program and data space in the SX. The idea that I'm pondering, but haven't fully fleshed out, is using a program that allows the PC to send data serially to the SX -- this would be the best way to fill the entire EEPROM.
As usual my choice of words fail me. I have 2 programs. One is AnimateSkull.SXB with all my data statements in it which is 77K and the VEX_Servos_EZ.SXB which has the code to capture the VEX controller and send the data out serially. So I guess what I meant was I have to "re-program" the SX not flash it when I want to switch between capturing movements and testing the data.
Right now it looks like my data is still too big even for the SX. Won't compile. I have about 2957 data statements of only 3 servos.
Which brings me to my next issue. I only have 3 values in my DATA statement but the code is written to move 4 servos. I have servos plugged into Pins 0,2,3 I pulled the servo from pin 1 because it is the jaw. So the code can move the pin if it wants but there is no servo. But it can only read 3 data elements so in the movement code I am doing
READINC pos0, pos2, pos3, timing
will this work or do I need to do something else to use only the 3 data elements with my servos?
Jeff
Just compressed down the DATA lines to 1097 by removing any entries with a timing of 1. But the program still won't compile.
The program code is 41k now.
It is often difficult to see things in isolation -- can you attach the whole program so I can have a look. Remember, too, that the SX has only 2K words of flash; your data statements are going way past that. I really think the key is going to be writing a program that receives the data serially and stuffs it into the EEPROM.
I'm confused. I thought that one of the big reasons for going with a Prop-SX for an animated head project was that the memory size for the program was MUCH larger than the Prop-2? If I have the same space limiatations on the SX that I do on the Prop-2 then why bother? I should try to condense down my movements into something that would fit on the Prop-2? If we can figure out how to get the the extra data statements onto the EPROM through the serial port that would be nice but I am slowly running out of time. This project has to be up and running in a month.
I realized what the real problem here is. Using the VEX capture program generates a LOT more data points than you would have if you were manually putting movements in Vixen or doing it in code. You'd might have 100-200 data statements for head turns,nods,tilts in a 2min show. But because we can use the VEX to capture movements in realtime the changes are much smoother and if played back would be more realistic. But it is more like 3000 data statements for 2min show. Even if I compress the changes down we are looking at 1100 data statements at least. Maybe I could create a threshold for the timing value when building the data and say that I only keep data statements with a time value of 5 or greater? That would reduce the statements quite a bit?
Here is the SXB code
www.davisgraveyard.com/AnimatedSkull.SXB (http://www.davisgraveyard.com/AnimatedSkull.SXB)
We have never claimed that the Prop-SX had more program memory, because it doesn't. That said, it does have a huge EEPROM (relative to the Prop-2) that is available for use that is completely separate of the program memory. The reason for using the Prop-SX is horsepower; the ability to do serial communications and servo stuff at the same time (e.g., with Vixen or VSA).
A project that I have on my list is a utility to download data from a PC into the SX EEPROM through the serial connection. The Prop-SX end is easy, I haven't sorted out the PC end. The easiest thing to do, I suppose, is create a program that simply dumps 32K of data into the SX. The SX has to control data flow because burning the EEPROM takes a few milliseconds per write, and the block size is just 16 bytes (I believe). At 10ms per block the full download would take about 21 seconds. Perhaps this is a project we can work on together as you do more PC programming than me.
I use a piece of video editing software called Vegas that has a neat feature. It lets you record volume or other analog changes in real time and then goes through and smoothes these data points with interpolation. By removing noise and small (non-deliberate) moves from the input the data points are reduced.
I don't know if it would have ill affect on your moves, but you could do a simple averaging on your data. Take five data points, average each channel, then use the average values for five cycles. It's simplistic, and may not give you the results you want -- but as with any experiment it will be educational.
I agree the horsepower of the SX is usefull for simultanious servo and comm stuff. But as I have already offloaded the jaw movement to a dedicated board and most of the show is sequencial the Prop-2 works. Now if we can get 32K of data statements burned into the EPROM THAT would be something. I'm surprised there isn't a way to do that now either in the SX/B IDE or a stand alone utility. I would be glad to help write a PC program to do it if you want my help.
I have modified my DATA statement creator to skip the fine detail movements and only keep ones based on a threshhold. It works to get the data down to a reasonable size but I haven't been able to test it yet.
For the time being I have moved back to the Prop-2. I have been munging the data statements and can get it down from 3000 to about 495 and it fits into the Prop-2. I did notice that the same process does NOT fit into the Prop-SX. The Prop-SX program is larger so there is less room for the Data Statements and even at 300 statements I couldn't get it to compile.
So I'd like to ask the question again for the 3rd time. What calculation do I need to change my 100-200 range values from the VEX program to be used in a Prop-2? Is it just a factor of 5 like going from a Prop-1 to a Prop-2?
Jeff
I have converted my DATA statements to values that are a factor of 5 from the VEX values. But my Prop-2 program doesn't move the servos the same as they were in the VEX? It seems like those values are forcing the servos to far to the extream? For example.
These are the VEX values
DATA 172,161,162,15
DATA 177,161,162,7
DATA 182,161,162,6
DATA 184,161,162,6
DATA 187,161,162,6
DATA 188,161,162,10
DATA 190,161,162,26
DATA 190,161,162,15
DATA 189,161,162,9
DATA 155,162,162,6
DATA 130,162,162,6
DATA 124,162,162,9
DATA 122,162,162,6
DATA 124,162,162,31
These are * 5 for the Prop-2
DATA 860,805,810,15
DATA 885,805,810,7
DATA 910,805,810,6
DATA 920,805,810,6
DATA 935,805,810,6
DATA 940,805,810,10
DATA 950,805,810,26
DATA 950,805,810,15
DATA 945,805,810,9
DATA 775,810,810,6
DATA 650,810,810,6
DATA 620,810,810,9
DATA 610,810,810,6
DATA 620,810,810,31
But the movements aren't the same?
I wasn't clear. You could take five lines an average each column. Then drop column four and replace that with 5 for the five cycles that these values will hold. Hence:
DATA 172,161,162,15
DATA 177,161,162,7
DATA 182,161,162,6
DATA 184,161,162,6
DATA 187,161,162,6
... becomes:
DATA 180, 161, 162, 5
This s a simple form of digital filtering.
If you decide to go back to the Prop-SX you can use the attached program do download 1K data chunks. Simply change the DATA table (256 rows of four bytes) and the EE_BLOCK (0 to 31, each block is 1024 bytes) number. The starting address for the data is calculated from EE_BLOCK. An LED flashes rapidly while downloading and if all goes well it will extinguish. If an error is detected (each byte is read back after written) then an second LED flashes to let you know there was an issue.
The short example I gave was already filtered down from the one below. I could try your approach but I just filtered out the time values less than 6 and added them to the next value until it became at least 6. I was trying to keep the time the same with less entries so the show took the same amount of time with less data entries. If I average the values then the time values will be shorter and then the movements will be done before the speech right?
DATA 172,161,162,15
DATA 173,161,162,2
DATA 174,161,162,1
DATA 175,161,162,3
DATA 176,161,162,1
DATA 177,161,162,4
DATA 178,161,162,2
DATA 179,161,162,2
DATA 180,161,162,1
DATA 181,161,162,3
DATA 182,161,162,2
DATA 183,161,162,5
DATA 184,161,162,2
DATA 185,161,162,4
DATA 186,161,162,2
DATA 187,161,162,2
DATA 188,161,162,10
DATA 189,161,162,1
DATA 189,162,162,1
DATA 189,161,162,2
DATA 190,161,162,25
DATA 190,162,162,1
DATA 190,161,162,15
DATA 190,162,162,1
DATA 190,161,162,3
DATA 189,161,162,3
DATA 189,162,162,1
DATA 189,161,162,5
DATA 188,162,162,1
DATA 187,161,162,1
DATA 186,161,162,1
DATA 185,161,162,1
DATA 184,161,162,1
DATA 183,162,162,1
DATA 181,162,162,1
DATA 180,162,162,1
DATA 179,162,162,1
DATA 178,162,162,2
DATA 177,161,162,1
DATA 176,162,162,1
DATA 175,161,162,1
DATA 173,162,162,1
DATA 172,162,162,1
DATA 170,162,162,1
DATA 169,162,162,1
DATA 167,162,162,1
DATA 166,161,162,1
DATA 165,162,162,1
DATA 164,162,162,3
DATA 164,161,162,1
DATA 163,162,162,1
DATA 163,161,162,2
DATA 162,162,162,1
DATA 161,162,162,1
DATA 160,162,162,1
DATA 159,162,162,1
DATA 157,162,162,1
DATA 155,162,162,2
DATA 154,162,162,1
DATA 152,162,162,1
DATA 150,162,162,1
DATA 149,162,162,1
DATA 148,162,162,1
DATA 147,162,162,1
DATA 146,162,162,1
DATA 145,161,162,1
DATA 144,162,162,1
DATA 142,161,162,1
DATA 141,162,162,2
DATA 140,161,162,1
DATA 140,162,162,1
DATA 139,161,162,1
DATA 138,162,162,1
DATA 137,162,162,1
DATA 136,162,162,2
DATA 135,162,162,2
DATA 134,162,162,1
DATA 134,161,162,1
DATA 134,162,162,1
DATA 133,161,162,1
DATA 133,162,162,2
DATA 132,162,162,1
DATA 131,162,162,1
DATA 130,162,162,1
DATA 130,161,162,1
DATA 130,162,162,2
DATA 129,162,162,1
DATA 128,162,162,1
DATA 127,162,162,2
DATA 127,161,162,1
DATA 126,162,162,2
DATA 125,161,162,1
DATA 125,162,162,3
DATA 124,162,162,5
DATA 123,162,162,1
DATA 122,162,162,6
DATA 123,162,162,1
DATA 122,162,162,1
DATA 123,162,162,3
DATA 124,162,162,29
Still not sure why my Prop-2 PULSOUT values from my DATA statements are not working? Is there more to it than just multiplying the VEX values by 5?
Jeff
If you setup your run-time engine such that the last entry in the record is the number of repeats, then no, you will not have your data finish ahead of your audio.
I frequently convert BS1 programs to the BS2 by multiplying the BS1 PULSOUT value by 5; works all the time.
[Edit] I added your servo values to my 3x Servo engine and did some tweaking (as well as fixing a typo that was overwriting the servo 1 position data). I changed some pin assignments so please check the definitions sections. It works.
So the Prop-SX VEX program from this tread outputs the same values as a Prop-1? But when I multipy the values by 5 and do PULSOUT the servos are not moving the same way?
As for the timing issue I don't think you understood. You suggested doing an average sampling to reduce the data but if I reduce the DATA statements I need to keep the repeat count the same so show timing stays the same. So I can average the PULSOUT values but need to sum the repeat values. My issue is that the orginal captured data has a LOT of repeat values of 1 or 2 because of the granular nature of the data. I have almost 3000 statements to begin with. 60% probably have repeat values of 1. The guts of the real changes are about 400 statements. But I have to maintain the repeat count of the orginal 3000 statements so the show time stays the same right?
jeff
See the program I attached above -- it works. What we both did, I'm guessing, is connect the servos to P0-P2 and those pins had not been made outputs (that's now fixed). I also found an error in the code that reads the servo data which was causing the servo 1 position value to be overwritten by the servo 3 value.
Jon, you are freak'n AWSOME! It works!!!!!!
I like the multiplier on the read. That way the data stays the same. IT works GREAT. I'll have to take a video and show you how it all works! I think I have something I can work with.
I will still try to work with the Prop-SX and see if I can program the data into the EPROM. It would be nice to have a little bit more detail for the head movements.
again, THANKS!
Jeff
I rule! ;D Now go watch and vote for "Strangers" (see Misc. forum).
Cool video! Chris and I both watched it. Voted thumbs up and sent to fellow haunters.
I spoke too soon about my program. The servos are working great and the data read is fine. It is just a timing issue with the show. My show is ending before the audio and then starting again before it has finished.
One of the issues is program structure. I have attached it so you can take a look. I need to add a couple more LED fades at the beginning and ending for spotlights before the eyes but thats not the problem.
I also think my repeat count isn't correct for the data. The repeat counter isn't high enough so it ends too soon. I totaled up the orginal files repeats and they came to 6225 when I added up the ones in the DATA statements they are 3663. I will check my program that munges the data to see how I am loosing them.
Any pointers would be appreciated....again thanks for all the help.
Jeff
I fixed my problem with my data munging routine and now can create 400+ DATA statements with the proper number of repeats.
Made a few changes to the code. Still having issue with the show ending before the audio is done. The MP3 length is 0:01:54.
I have 424 DATA statements with a total of 6257 repeats. I bumped the Refresh_Servos routine PAUSE to 20. That would make 125.14 seconds but the show finishes reading all the data before the MP3 finishes? What am I missing?
Jeff
Herein lies the problem with the BS2 in this kind of application. While easier to program it is less precise than the Prop-SX (this is not a knock, just the way things work). Here's what I mean: Let's say that you collect servo data every 20 milliseconds. Great, no problem. With the Prop-SX we can create a background process that loads new servo values every 20 milliseconds -- right on the dot. We can't do that with the BS2. Why? Because we can only run a single thread. What we're forced to do is take a compromise position on loop timing. In your case you have three servos use a total of 3 to 6 milliseconds depending on their positions. So what value do you use to pad the loop for 20 milliseconds? I would start with 15 since the average time consumed by the servo pulses should be on the order of 4.5 milliseconds and you have other overhead. My point is that you're going to have to experiment with your loop padding to so that your show data more closely matches the track that you used to record the moves.
[Edit] I had a look at your program. If possible, crank up the baud rate to/from the uMP3 to 38.4K as this will minimize TX/RX delays. Also, remove the RETURN from Get_Record so that it drops through to Refresh_Servos; this will help, especially in the beginning where yo have a long fade-up with no refreshing of the servos.
Looking over your program and keeping the previous thoughts in mind I came up with this idea:
Refresh_Servos:
PULSOUT Servo1, pos1 * 5
PULSOUT Servo2, pos2 * 5
PULSOUT Servo3, pos3 * 5
dPad = (pos1 + pos2 + pos3 + 50) / 100
PAUSE 20 - dPad
RETURN
The idea here is to calculate -- to the nearest millisecond -- the amount of time used by the servo pulses. Perhaps this will get the loop timing closer and help it keep sync.
Also, I would remove the status check of the uMP3 that's in the middle of the play loop; once you've got sync you really shouldn't need that.
I implemented all your suggestions but still was coming up short on the show. So I incremented the PAUSE value in the Refresh_Servos until it worked. I ended up making it PAUSE 40 - dPad before it worked.
THe problem with such delays is the head movements are pretty choppy. So I set it back to PAUSE 20-dPad and added a PAUSE 15 in the repeats loop. To slow down the refresh between each repeat. Basically did the same thing. Still choppy.
I had an idea. It might take a bit of coding but I wonder if we can smooth out the movement and extend the timing by calculating the difference between one read and another
so if I read
DATA 164, 161,162,20
I store pos1-3 values to oldpos1-3 values
then read
DATA 172,161,162,13
and instead of just jumping to the new value I increment/decrement the pos1-3 one at a time and refresh within the number of repeats. SHould make the movement less choppy and will add some more time to the show?
What do you think?
I'm torn... it seems like you're now trying to code around the massaging of the original data. I've updated your program and even tried to improve the loop timing by replacing the big PAUSE in the servo section with a PULSOUT which is much more precise (luckily, you have spare pins).
This version will take the new servo value and the last and average them, so you will have to tweak the loop timing and you may need to tweak the repeats column as well.
Not really code around the orginal data massage as much as correct a side effect of stretching out the timing. If we play the data with little or no delay then it is almost as smooth as the orginal data. But with the delay to stretch it out to fit the show it is very choppy. But I did notice on the first few passes that the massaged data (in order to get it to fit on the Prop-2) was a bit sloppier than the orginal VEX movements. But I figured I could live with it even if it was a bit "robotic".
My new coding idea was more of a way to go back to the orginal data without having to store it all as DATA statements. The massaging I did is really just removing all the single PULSOUT changes over time so what I ended up with is the major position changes with large repeat values. So the servo jumps to a new position and waits there. If we did separate PULSOUT's incrementally between those changes it would probably be smoother and take a bit longer to get there? This would get rid of the effect we are seeing right now which is robotic. and the introduced delay makes it choppy on top of it.
I will try your new code and see what kind of difference it makes.
Thanks for all the help.
Jeff
Wow! That did NOT work! Threw the head around and then crashed. I didn't edit the program just loaded it as is.
So did anyone find a way to import the VEX built movements into VSA?
Funny you should ask. I was just thinking tonight about another approach to my whole Prop-2 and Prop-SX DATA storage issue. I've been trying to do this talking skull without tying it to a PC but I'm not happy with the tradeoff off less data points which translates to less smooth movements. I REALLY liked the way the head looked when moved with the VEX transmitter. But that created over 3000 data points. So now I'm thinking what if I put that in VSA or Vixen and just played it back? If I'm going to bite the bullet and go with a PC then I can also drop the uMP3 and just play the audio with the PC. Now the prop controller is just a dedicated servo controller driven by the show software.
So now I too would like to know how I can import my data into either VSA or Vixen. And what would the connection be from the PC to the Prop controler and should I use a Prop-SX or a Prop-2?
Jeff
I'm using an SX...so I'd be interested in that.
VSA has an import option but I've not used it. I'm assuming (that's dangerous) that since it exports CSV it may want to import it that way has well. Here's the danger for you, though: you recorded data at 20ms and VSA's fastest frame rate is 33ms.... Still, it might be worth a try.
What about Vixen? Is that more limited or just the same as VSA? Or does Vixen even have an import option?
Jeff
Jeff,
Have you thought of massaging the data so you don't need as many data points? Similar to how VSA treats a servo, from position 1 to position 2 in a period of time. The Prop-2 code would then need to interpret the three data points instead of a datapoint every 20ms. This would dramatically decrease the amont of data you would need. I'm not sure the prop-2 would be able to do this, but I think the Prop-SX could.
Greg
To my knowledge, Vixen doesn't have an import function.
It would probably be ok that VSA has a 33ms limit. I could scale my data points down to a minimum of 2 repeats (40ms) which is about 1800 data points.
Too bad Vixen doesn't have a way to paste in your data instead of doing it with the GUI? I'll check into VSA to see if it does the import like you think it might. I'd like to give this a try.
I assume no matter what, I am still going to have to go with a external power supply for my servos because of the power regulator on the Prop-SX or Prop-2?
If you're using VSA it might actually be quicker to rebuild the show. VSA has a live capture function (one tract at a time while the audio and other tracks play) that even has a smoothing function for the data. I've not used this yet -- just read about it in the help file.
Yes, I think for your skull you're going to need an external power board. I've run lots of servos from our controllers, but not of them under particularly heavy loads.
So one of the reasons I never wanted to go the VSA route was because of the teathered PC to the prop concept. So what is the most common way people connect a PC running VSA to a prop controller in a prop from a long distance. I would want the PC to be in the house and the prop is probably 25-50 feet way?
Use the lowest possible baud rate that VSA says will work with your routine (it has a bandwidth analysis feature). RS-232 is actually supposed to be fine up to 50 feet, and the lower the baud rate (which fights cable capacitance) the better. What you want to ensure, though, is that your PC is sending true RS-232 levels (+/-15 volts) and not "RS-232 compatible levels" that are generally in the +/-5 volt range.
From Wikipedia: A widely-accepted rule-of-thumb is that for cables longer than 50 feet (15 meters), special effort will be required.
I wish I was better at PC programming; seems like it should be very easy to read the CSV export from VSA and dump it into a Prop-SX to run stand-alone. That said, I'm going to spend the morning crafting a Prop-SX RAPU program so that when I _can_ get the PC side going I have a Prop-SX that can accept the data and then play it back in stand-alone mode.
wouldn't you run into the same old storage limits droping a VSA show into a Prop-SX? Or are you talking about burning it into the 32K eprom? And even then if the show were too complicated would that not be enough pace for all the data?
I'm going to buy a copy of VSA next week and give this a try. I'll try setting it up from scratch and also importing my data. Once I have something running I can look into the export. I could probably write something quick that converts the data to something you could use?
Jeff
What I'm talking about is using all of the SX horsepower: use background servo processing to get the timing right and put the data into the 32K EEPROM -- that's why I need a PC program that can read the exported VSA data, massage it, then "talk" with my Prop-SX RAPU program that is in download mode. By using the 32K EEPROM instead of putting servo data into the actual code space you can have a 4-servo show run 4.55 minutes (at the 33ms rate of VSA). If you want four servos plus four PWM channels (which I think would be good for a skull) the show length drops to 2.25 minutes, but this is probably still long enough for most shows (our "customers" get bored quickly, no matter how cool our prop is). I'm going to try to be clever with my code so that the PC can tell the Prop-SX what the data means (just servos or servos+pwm, and the frame rate of the program [lower frame rate = longer show]).
Would it be possible to save the data file on a thumb drive and use a Vdrive2 interfaced with the SX to read in and buffer the data using a no preserve interupt routine? If its possible, the storage issue would solved. Only task left would be coding for the Vex or VSA/comma delineated formats.
http://www.mouser.com/Search/ProductDetail.aspx?qs=vnwGVgFuQiZQSHig5qjpOQ%3d%3d
I suppose it's possible. The funny think about FTDI is that while that make really cool products (like the VMUSIC2) they're not so good at providing useful examples. I think the VMUSIC is just an extension of the VDRIVE so -- when time permits -- I can look into reading CSV data from it using the Prop-SX.
That's said, I think people get bored with talking skulls that go more than a minute or so, and if that holds true we have plenty of storage space right on the Prop-SX
I was just brainstorming/daydreaming and thinking on a larger "show" scale than just a couple of talking skulls. It would be cool to be able to pull show routines in from a "library" on a thumbdrive. Master/slaveing/RS485, DMX, complex motor control, sound...might be alittle grandiose but I am just thinking...
Stop dreaming, start coding! ;D
I was wondering, would it be possible to modify the program of this thread to burn the data it sends out the serial port to the SX EPROM?
I took a look at my captured data of a 2min session using this program and it is 35K. Some of this could be reduced since I only use 3 servos for capture and there is a lot of duplicated data at the begining and end of the session since the servos sit for several seconds as the audio starts and ends.
The file I create using a PC to format the captured data into DATA s1,s3,s3,count is only 2957 lines. That would be 12K if you stored 4 bytes for each line. Although then you would have to keep a counter in the SX program for each 20ms frame and only write to the EPROM if any of the servo values changed. Using that method, if even possible, would allow you to store a HUGE show if you wanted.
Then you could use the VEX program to puppeteer your animatronic and then load the player and it would read the EPROM data and play the show back? Pretty simple process if it could be done? For me it would have to be next year but I would be half tempted to try it this year if it were possible?
Jeff
To be candid, Jeff, I don't know and like you, my time is so pressed right now I probably won't be able to know until after Halloween. It might be workable with fixed filtering/compression, though you would want to use a binary divider ( 2, 4, or 8 ) to simplify averaging of the data. Something like this (pseudo code):
PUT eeOut, 0, 0, 0, 0 ' clear samples
FOR idx = 1 TO 2 ' average by 2x
GET_VEX ' get raw channel data
FOR idx2 = 0 TO 3 ' loop through 4 channels
vex(idx2) = vex(idx2) >> 1 ' divide by 2
eeOut(idx2) = eeOut(idx2) + vex(idx2) ' accumulate / average
NEXT
NEXT
WRITE_EEPAGE eePntr, eeOut, 4 ' write bytes to EE
eePntr = eePntr + 4 ' update pointer
For the moment, anyway, I think there is too much jitter in the VEX output to do variable sampling/compression. With the scheme suggested above you could store 8192 records for four channels. Each record would run 2x the VEX timing rate of about 18.5 ms; this means each position has a minimum time of 37 milliseconds and the total show could be 303 seconds, or 5 minutes.
Interesting idea. Like you said I am way too busy too for any new code at this point. All my Prop controller code is written and is going to stay until after halloween. I've got too many other things to deal with than work on tuning code at this point.
We'll talk some more in November.
Jeff
I also am interested in putting data into the EPROM.
I would be interested in putting VSA data into the EPROM however.
My setup is set for this year, but would be interested in starting this discussion in November after the dust has settled.
On of the projects that I'm working on -- that will have to wait until after Halloween -- is a program that takes the data from a VSA export and converts/downloads it into a Prop-SX to be run stand-alone. I will post as soon as I have something for everyone to test.
Quote from: JonnyMac on September 29, 2008, 08:16:39 AM
On of the projects that I'm working on -- that will have to wait until after Halloween -- is a program that takes the data from a VSA export and converts/downloads it into a Prop-SX to be run stand-alone. I will post as soon as I have something for everyone to test.
Jon,
Any progress on this project? The holidays are over and I would like to convert my 3-axis skull from PC controlled to a stand alone unit.
It's still in the works, but at a lower priority than several key new products. That said, one of those new products shares a lot of the code, so I get a two-for-one deal with my programming! ;D