My thoughts...
What is the size of the speaker producing these sounds? IF it is only that tiny thing in the train then high fidelity is wasted.
Playing multiple stored wave files at the same time is problematic. Reading more than one sound at a time means leaping around the ram/rom/SD/ gathering sound bytes fast enough to keep up. Especially considering this storage is serially accessed and all the overhead in changing addresses. However, reducing the data rate and playing in mono would help. 44KHz stereo 16 bit is nearly 1.5 Mb/s (Mega bits per second) or 176 KB/s.
Many years ago I made a 'race announcer and countdown' device to start races in radio controlled model yacht race meetings. I sampled my own voice using a 'BBC Micro' at 10KHz and 8 bit. To my surprise the result was amazingly good! It was better than the telephone audio back then. It replaced a portable tape recorder at the time and everyone agreed it was a big improvement.
Of course I was only playing one sound at a time.
The total storage was 128 Kbytes (less than 13 seconds) stored in eeprom and was easily random accessed quickly.
What is the maximum number of sounds to be played simultaneously?
Hub ram is so small that at even 10KHz 8 bit only a few seconds could be stored.
Can the sounds be broken down into repeated loops?
If you had say six serial roms each with the same sounds on but each being able to be accessed simultaneously, and limiting the simultaneously played sounds to the number of roms, it should be easily doable.
I think with a series of compromises it could be done, but it might take up all the resources of a prop1.
actually it doesn't. At least not with fastspin. A while ago I was able to combine both, but that was for TAQOZ ROM version A. I really would like to try this with TAQOZ reloaded, but could not find out yet how much memory to reserve at the bottom of the HUB. ROM TAQOZ took 64K the newer one seems to need more.
I do not want to bother Peter, he needs to finish P2D2 but maybe you can help me there.
The basic concept is to tell fastspin to compile for code starting at $1000 (old ROM) so it might be $2000 now for TAQOZ (new ROM). I am not sure about the memory map of the current TAQOZ. So the fastspin compiled program starts itself at $1000 ($2000?) in COG1 and jumps COG0 into TAQOZ.
I did some patch for fastspin to automate the process and it was working nicely until Peter and Eric both changed things faster then I was able to follow.
So coexistence is - theoretically - possible and would be a nice way to integrate TAQOZ into spin.
you've slipped into P2 thinking. The board in question has a P1 so things are different.
Preprocessing the files would certainly save time and RAM at runtime, but then skipping a filesystem and just having raw block based storage for the audio would help too.
Depending on the sample length of the various sounds, it might be possible to keep a clean copy of the chuff and idle sounds (probably the most commonly played) in hub, and then overlay the other sounds into a buffer that is read continuously in a loop by a single PWM cog.
The other sounds could be fetched on demand if necessary, and summed into the buffer. Then on completion of that sound combination simply copy the clean loop back into the output buffer.
Then on completion of that sound combination simply copy the clean loop back into the output buffer.
The individual sound files could be mixed on a computer and saved to the SD card. This why each possible combination would be saved as a separate sound file. I'd think writing software to select the appropriate file would be easier than trying to combine the sounds using the Propeller.
Of course the transitions from single sounds to multiple sounds might not sound very good if using precombined sound files.
The individual sound files could be mixed on a computer and saved to the SD card. This why each possible combination would be saved as a separate sound file. I'd think writing software to select the appropriate file would be easier than trying to combine the sounds using the Propeller.
Of course the transitions from single sounds to multiple sounds might not sound very good if using precombined sound files.
That IS one way to to do it. Multiple sounds mixed on the left channel, and other sounds mixed on the right, and mute/unmute/load the proper mix combinations...
But the timing would be kinda locked together....
I will need to think about that, and write a matrix of sound combinations with sound lengths and see if it will work.
I think I may AT LEAST need 4 channels of audio. (so 2 stereo files)
That still means two stereo files playing back simultaneously.
I wouldn't have a problem combining TWO propeller chips, or three, or four..
Technically if I have two prop chips, one that does everything, and the other that does all the sound....
I could connect 3 or 4 sd cards to the second sound prop chip and run multiple sound cogs that each access their own sd card independently on different pins with different audio out pins, which are combined externally......
HMMMM
At least for G-scale engines, plenty of room.
I did multiple props with my blackbox, one can clock the other to stay in perfect sync.... etc... I was able to fit all the code on one eeprom, one xtal, and have one prop program all the others, and output the 5mhz clocks.
You can see the eeprom (smt) and the socket for the prop plug at the very bottom center prop.
actually it doesn't. At least not with fastspin. A while ago I was able to combine both, but that was for TAQOZ ROM version A. I really would like to try this with TAQOZ reloaded, but could not find out yet how much memory to reserve at the bottom of the HUB. ROM TAQOZ took 64K the newer one seems to need more.
....
Mike
Hi Mike
as @AJL said - we are on P1 here.
@"Clock Loop"
when you talk about using more HW, multiple props, ... etc.
Then maybe think about it.
You can stick with your existing SW and compensate limitations of the language/environment (SPIN) with HW.
@"Clock Loop"
I wouldn't have a problem combining TWO propeller chips, or three, or four..
Technically if I have two prop chips, one that does everything, and the other that does all the sound....
I could connect 3 or 4 sd cards to the second sound prop chip and run multiple sound cogs that each access their own sd card independently on different pins with different audio out pins, which are combined externally......
HMMMM
OR you could do a stretch / leap jump and go for Tachyon with just one P1.
I want to give some numbers to Peter's proposal of merging several sound files realtime with Tachyon.
Looking at EASYFILE he states
170312 Improved sector read time to 1ms
so thats 512kByte/s
a 8 bit mono at 10kHz is just 80kB/s
so you can do 6*80 = 480kB/s
(you really need 6 sounds overlapped?)
IF you store the sound files UNFRAGMENTED on SD so they can be read in sequence without FS overhead.
Standard in EASYFILE are 4 file handles with 4 file buffers.
But with little tricks you can just use those file buffers for the data handling
In a loop a sector of each file is read alternating into the always same buffers 1&2
A second COG can do the combination into one of the buffers #3/#4,
like adding them up and doing some normalization. 2 = rsh 1, 4 = rsh 2
Don't know if an extra COG would probably be used to feed the data out to the pin - or a 10kHz 'interrupt' could do this.
if two combination buffers (#3/#4) are used alternating
calculating one and playing the other then there won't be any switch over lag
Sound combination could only be started at buffer borders (160 times / second) - noone will realize this ;-)
The other functions I have seen you talking about should be really easy with all the tools in EXTEND.
Like PWM, sensor readings, blinking LEDs, SPI, I2C ... all without any additional libraries
Of course - changing horses during the race ... - but sometimes makes sense, when one horse can't run any more.
And you can get a young and strong one ...
Of course I know and like Tachyon and I am a bit biased ... ;-)
but there was a time ... when I had no idea about Forth and Tachyon ....
so it is possible to learn it
AND it is fun
The individual sound files could be mixed on a computer and saved to the SD card. This why each possible combination would be saved as a separate sound file. I'd think writing software to select the appropriate file would be easier than trying to combine the sounds using the Propeller.
Of course the transitions from single sounds to multiple sounds might not sound very good if using precombined sound files.
That IS one way to to do it. Multiple sounds mixed on the left channel, and other sounds mixed on the right, and mute/unmute/load the proper mix combinations...
But the timing would be kinda locked together....
I will need to think about that, and write a matrix of sound combinations with sound lengths and see if it will work.
I think I may AT LEAST need 4 channels of audio. (so 2 stereo files)
That still means two stereo files playing back simultaneously.
I wouldn't have a problem combining TWO propeller chips, or three, or four..
Technically if I have two prop chips, one that does everything, and the other that does all the sound....
I could connect 3 or 4 sd cards to the second sound prop chip and run multiple sound cogs that each access their own sd card independently on different pins with different audio out pins, which are combined externally......
HMMMM
At least for G-scale engines, plenty of room.
I did multiple props with my blackbox, one can clock the other to stay in perfect sync.... etc... I was able to fit all the code on one eeprom, one xtal, and have one prop program all the others, and output the 5mhz clocks.
You can see the eeprom (smt) and the socket for the prop plug at the very bottom center prop.
I think I do want to stick with the prop, and spin / prop asm(objects that other users create), I am not looking to change languages, I don't even want to move to C, even though there are many examples here.
I am slowly understanding how to talk to the wifi WX module IN SPIN, and so far so good, all the examples are in C, but soon, my examples will be here, in SPIN.
I am hoping to do this in prop spin with objects in the GITobexHUB, and then once I have a working setup, moving my train, possibly with a second prop doing the sound, ,....(unless someone can barf some code up to make it happen on the first prop)
Then I will start to look what it will take and what can be done with a P2. Hoping that many GITobexHUB objects will be created by that time...
Not sure if you know it, but that black box sequencer/synth is SUPPOSED to be large and gawdy, the row of LEDS light up, and are the actual buttons also. IT OUTPUTS SPDIF DIGITAL AUDIO or regular analog... It can be connected to as many other black boxes as the user creates.... Yes, LEDS as buttons, thats why they are glowing, there is a CCFL tube mounted on the other side above the leds, (that image is the backside) It was a labor of love to put into practice the ability to use a LED as a sensor (a tribute to forrest mims), so is the Mims Mirror. https://hackaday.io/project/16788-mimsmirror
I had no desire to make it small, or do it on a 'TM1638' !
I think I do want to stick with the prop, and spin / prop asm(objects that other users create), I am not looking to change languages, I don't even want to move to C, even though there are many examples here.
I am slowly understanding how to talk to the wifi WX module IN SPIN, and so far so good, all the examples are in C, but soon, my examples will be here, in SPIN.
I am hoping to do this in prop spin with objects in the GITobexHUB, and then once I have a working setup, moving my train, possibly with a second prop doing the sound, ,....(unless someone can barf some code up to make it happen on the first prop)
Then I will start to look what it will take and what can be done with a P2. Hoping that many GITobexHUB objects will be created by that time...
Not sure if you know it, but that black box sequencer/synth is SUPPOSED to be large and gawdy, the row of LEDS light up, and are the actual buttons also. IT OUTPUTS SPDIF DIGITAL AUDIO or regular analog... It can be connected to as many other black boxes as the user creates.... Yes, LEDS as buttons, thats why they are glowing, there is a CCFL tube mounted on the other side above the leds, (that image is the backside) It was a labor of love to put into practice the ability to use a LED as a sensor (a tribute to forrest mims), so is the Mims Mirror. https://hackaday.io/project/16788-mimsmirror
I had no desire to make it small, or do it on a 'TM1638' !
Im a parallaxian!
Fellow parallaxians, unite and SPIN!
ok then - of course you can use SPIN and as many props as you like ...
no more suggestions for less Props and Tachyon from my side
but I will watch your progress ;-)
I am still working on this diligently, but I am running into esp module command mode bugs,,, (and spin example bugs)
So my spin code to get the webpage control working has slowed to a crawl.
The code just puts the WX module in to command mode, sets up a listener, and polls for the webpage's request,
it does not send the reply to the webpage, and then it just exits command mode. So a number will NOT show up in the webpage box.
CON
_CLKMODE=XTAL1 + PLL16X ' The system clock spec
_XINFREQ = 5_000_000 ' Crystal
Rx = 31 'serial in from wx device
Tx = 30 'serial out to wx device
OBJ
ser: "FullDuplexSerial.spin"
VAR
long Stack1[100]
Pub Main
cognew(Comms, @Stack1)
Pub Comms | CommandMode
ser.Start(RX, TX, 0, 115200) 'Cog #2
waitcnt(80_000_000 + cnt) 'wait 1 second fpr serial to start.
Repeat
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[2J")) 'Clear putty telnet screen.
If CommandMode == 1 'Turn command mode on in spin.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[2;3f")) 'Set Position in putty.
ser.str(string("Command Mode is On. ")) 'Tell putty command mode is on.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[1;1f")) 'Set Position in putty to put cursor at 0
waitcnt(80_000_000 + cnt) 'wait 1 second for serial to stop.
ser.Stop 'Turn off serial to send break.
dira[TX]~~ ' Set direction to output
outa[TX]:= 0 ' Set TX low.
waitcnt(80_000_000 + cnt) 'wait 1 second for command mode to start in the module.
dira[TX]~ ' Set direction to input
ser.Start(RX, TX, 0, 115200) 'Cog #2
waitcnt(80_000_000 + cnt) 'wait 1 second for serial to start.
ser.tx(254) 'Begin marker
ser.str(string("LISTEN:HTTP,/tpfm")) 'Tell the module to listen to a specific path on http port 80.
ser.tx(13) 'End marker
waitcnt(80_000_000 + cnt) 'wait 1 second
Repeat 5
ser.tx(254) 'Begin marker
ser.str(string("POLL:")) 'Tell the module to listen to a ANY protocol/path IN TEXT FORM. DO NOT FORGET THE COLON.
'ser.str(string($EC)) 'Tell the module to listen to ANY protocol/path in TOKEN FORM.
ser.tx(13) 'End marker
waitcnt(80_000_000 + cnt) 'wait 1 second
ser.tx(254) 'Begin marker
ser.str(string("SET:cmd-enable,0")) 'Turn command mode off in the WX module.
ser.tx(13) 'End marker
CommandMode := 0 'Turn command mode off in spin.
waitcnt(80_000_000 + cnt) 'Wait for 1 s
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[2;3f")) 'Set Position in putty.
ser.str(string("Command Mode is Off.")) 'Tell putty command mode is off. '
ser.str(string(27)) 'Set ansi command mode in putty. '
ser.str(string("[1;1f")) 'Set Position in putty to put cursor at 0
Repeat 5
waitcnt(80_000_000 + cnt) 'Wait for 1 s
CommandMode := 1 'Turn command mode on in spin.
Here is the same program that collects the reply and if it ever sees the proper reply from the webpage, it will send "Good Reply" to putty.
If it doesn't then it will send "Bad Reply".
It also sends the data with the reply, which will show up in the box on the webpage.
Which will be the number of loops the code runs through, up to 254 then will roll over to 0.
CON
_CLKMODE=XTAL1 + PLL16X ' The system clock spec
_XINFREQ = 5_000_000 ' Crystal
Rx = 31 'serial in from wx device
Tx = 30 'serial out to wx device
OBJ
ser: "FullDuplexSerial.spin"
VAR
byte LoopCounter
long Stack1[100]
Pub Main
cognew(Comms, @Stack1)
Pub Comms | CommandMode, Reply1, Reply2, Reply3, Reply4, Reply5, Reply6, Reply7, ReplyStatus
ser.Start(RX, TX, 0, 115200) 'Cog #2
waitcnt(80_000_000 + cnt) 'wait 1 second for serial to start.
Repeat 'The main repeat loop.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[2J")) 'Clear putty telnet screen.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[4;3f")) 'Set Position in putty
If ReplyStatus == 1
ser.str(string("Good reply.")) 'If last reply was good, put it back up on putty which was cleared.
Else
ser.str(string(" Bad reply.")) 'If last reply was bad, put it back up on putty which was cleared.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[5;3f")) 'Set Position in putty to put cursor at 0
ser.str(string("Loop count number that should be shown on webpage: ")) '
ser.dec(LoopCounter)
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[1;1f")) 'Set Position in putty to put cursor at 0
If CommandMode == 1 'Check for command mode on in spin.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[2;3f")) 'Set Position in putty.
ser.str(string("Command Mode is On. ")) 'Tell putty command mode is on.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[1;1f")) 'Set Position in putty to put cursor at 0
waitcnt(80_000_000 + cnt) 'wait 1 second for serial to stop.
ser.Stop 'Turn off serial to send break.
dira[TX]~~ ' Set direction to output
outa[TX]:= 0 ' Set TX low.
waitcnt(80_000_000 + cnt) 'wait 1 second for command mode to start in the module.
dira[TX]~ ' Set direction to input
ser.Start(RX, TX, 0, 115200) 'Cog #2
waitcnt(80_000_000 + cnt) 'wait 1 second for serial to start.
ser.tx(254) 'Begin marker
ser.str(string("LISTEN:HTTP,/tpfm")) 'Tell the module to listen to a specific path on http port 80.
ser.tx(13) 'End marker
waitcnt(80_000_000 + cnt) 'wait 1 second
ReplyStatus := 0 'Set the reply to bad so it can recheck for a new reply.
Repeat 10
ser.rxflush
ser.tx(254) 'Begin marker
ser.str(string("POLL:")) 'Tell the module to listen to a ANY protocol/path.
ser.tx(13) 'End marker
Reply1 := ser.rxtime(1) ' should be 254
Reply2 := ser.rxtime(1) ' should be =
Reply3 := ser.rxtime(1) ' should be G
Reply4 := ser.rxtime(1) ' should be ,
Reply5 := ser.rxtime(1) ' should be 5 (this could change)
Reply6 := ser.rxtime(1) ' should be ,
Reply7 := ser.rxtime(1) ' should be 1
waitcnt(80_000_000 + cnt) 'Wait for 1 s
'
If Reply1 == 254 And Reply2 == "=" And Reply3 == "G"
ReplyStatus := 1 'Set the reply to good so it can be shown in putty.
ser.tx(254) 'Begin marker
ser.str(string("REPLY:")) 'Tell the module to send a reply to the poll response.
ser.tx(Reply5) 'Should be a number. An active connection handle; returned by POLL.
ser.str(string(",")) 'Required for a reply
ser.str(string("200")) 'The desired HTTP response code for the reply.
ser.str(string(",")) 'Required for a reply
If LoopCounter < 10
ser.str(string("1")) 'Tell the module how many bytes? (or is this digits?) the reply is.
Elseif LoopCounter > 9 AND LoopCounter < 100
ser.str(string("2")) 'Tell the module how many bytes? (or is this digits?) the reply is.
Else
ser.str(string("3")) 'Tell the module how many bytes? (or is this digits?) the reply is.
ser.tx(13) 'End marker
ser.dec(LoopCounter) 'Send 1 byte (which is up to 3 characters (in decimal) (254) of data to the module which then sends it to the webpage.
waitcnt(80_000_000 + cnt) 'Wait for 1 s
ser.tx(254) 'Begin marker
ser.str(string("SET:cmd-enable,0")) 'Turn command mode off in the WX module.
ser.tx(13) 'End marker
CommandMode := 0 'Turn command mode off in spin.
'
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[2;3f")) 'Set Position in putty.
ser.str(string("Command Mode is Off.")) 'Tell putty command mode is off.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[4;3f")) 'Set Position in putty to put cursor at 0
If ReplyStatus == 1
ser.str(string("Good reply."))
Else
ser.str(string(" Bad reply."))
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[5;3f")) 'Set Position in putty
ser.str(string("Loop count number that should be shown on webpage: ")) '
ser.dec(LoopCounter)
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[1;1f")) 'Set Position in putty to put cursor at 0
Repeat 5
waitcnt(80_000_000 + cnt) 'Wait for 1 s
CommandMode := 1 'Turn command mode on in spin.
LoopCounter++
If LoopCounter > 254 'Deal with rollover.
LoopCounter := 0
Well, I drove it down the track, and at 14v, the vdrop over the full wave rectifier was too much, as soon as the motor barely started, the power dropped (due to bad power pickup on the wheels im sure).
So I pushed the voltage up to 18v with the vdrop puts the activity board to 16v, not to mention the increasing drop when the motor starts to pull more current...
That worked, until it reached a switch which I didn't wire properly, hehe, I need to run more feeder wires.
I am not doing dcc yet, thats quite far off in the future, I would need a dcc command station first... (#$%#$%# dont get me started)
I wanted to install a 6800uf capacitor on the 3.3v supply, but I found some of the circuitry on the activity board wx uses 5v (like the a2d chip that I am going to use to monitor the motor current.
So after looking at the circuit, I think I need to use the VIN still, but install some diodes so my 25v 2200uf cap doesn't reverse feed the motor supply (which has its own 6800uf 50v cap).
At this point I am getting a modified circuit that might have unintended consequences, so, it would be wise to finish the schematic to let others here see it and point out where I might go wrong and fry everything.
A wx board, with a wx esp module, and a dual motor board.... it would suck to fry it all.
Heres some crappy code that I am using to run it all.
The sound parts and the chuff sensor were disabled because I am using too many cogs (its the sound doing it, due to using up to 3 or more cogs i think, the waves don't block so multiple waves try to start, i dunno.
All the more reason to do the sound with another prop, unless someone comes up with a multi wave player (but the sd access is an issue?)
Again, another reason to do the sound on another prop with multiple sd cards and multiple sound engine outputs that mix externally.
Heres some garbage code that does work.
This code WILL NOT WORK, most of it was omitted due to forum body text limits, download the attached zip to see complete code.
This only shows the communications with the index.html file.
{{
Spin code by Clock Loop, made to only test 1 motor on the M1 pins, and the axle sensor to trigger the wav file chuff.
The code communicates with the wx module, and the index.html motor control VERY BASIC webpage.
As usual upload the index html to your wx module: Visit http://192.168.4.1/files/index.html
The attached zip contains the index.html file, it looks like Smile, i didn't include the .css or .jpg files.
}}
CON
Pub Main 'Cog #1
cognew(Comms, @SmokeStack3) 'Cog #5
MotorFwdFull 'Start motor drive. (Cog #1)
PUB MotorFwdFull
dira[M1IN1]~~ ' Set direction to output (Controls for Motor 1)
dira[M1IN2]~~ ' Set direction to output (Controls for Motor 1)
dira[M1D1]~~ ' Set direction to output (Controls for Motor 1)
dira[M1D2]~~ ' Set direction to output (Controls for Motor 1)
dira[SLEW]~~ ' Set direction to output (Slew Controls for Motor 1 and 2)
dira[EN]~~ ' Set direction to output (Enable Carrier Board)
dira[VDD]~~ ' Set direction to output (Enable Carrier Board)
outa[VDD] := 1 ' Set Pin VDD to high to enable PULL up resistors, NEVER connect this to VIN.
'
outa[Slew] := 1 ' Set Pin SLEW Output slew rate selection input. A logical LOW results in a slow output rise time (1.5 us - 6 us).
' A logical HIGH selects a fast output rise time (0.2 us - 1.45 us).
' This pin should be set HIGH for high-frequency (over 10 kHz) PWM. This pin determines the slew rate mode for both motor driver ICs.
' Setting this to a 1 with a duty of 1000 also works.
outa[M1IN1] := 0 ' The logic input control of OUT2. PWM can be applied to this pin (typically done with both disable lines inactive) Reversing the setings on Pins M1IN1 & M1IN2 will reverse motor direction
outa[M1IN2] := 1 ' The logic input control of OUT1. PWM can be applied to this pin (typically done with both disable pins inactive) Reversing the setings on Pins M1IN1 & M1IN2 will reverse motor direction
'outa[M1D1] := 1 ' Disable input: when D1 is high, OUT1 and OUT2 are set to high impedance.
' A D1 PWM duty cycle of 70% gives a motor duty cycle of 30%.
' Typically, only one of the two disable pins is used, but the default is for both disable pins to be active.
'outa[M1D2] := 1 ' Disable input: when D1 is high, OUT1 and OUT2 are set to high impedance.
'A D1 PWM duty cycle of 70% gives a motor duty cycle of 30%.
'Typically, only one of the two disable pins is used, but the default is for both disable pins to be active
outa[EN] := 1 ' Set Pin (EN)to high to enable carrier board
pwm1.start(M1D1) 'Cog #6
pwm2.start(M1D2) 'Cog #7
pwm1.SetPeriod(MotorFreq)
pwm2.SetPeriod(MotorFreq)
repeat 'super lame way to do motor control. very basic and hacky.
waitcnt(80_000_000 + cnt) 'wait 1 second before next update
If Speed <> CurrentSpeed
repeat CurrentDuty from CurrentSpeed to Speed 'linearly advance speed
pwm1.SetDuty(CurrentDuty)
pwm2.SetDuty(CurrentDuty)
repeat 2
waitcnt(80_000_000 + cnt) 'wait 1 second before next update
CurrentSpeed := Speed
Pub Comms
dira[TX]~~ ' Set direction to output
outa[TX]:= 0 ' Set TX low.
waitcnt(10_000_000 + cnt) 'wait 1/10 second for command mode to start in the module.
dira[TX]~ ' Set direction to input
ser.StartRxTx(RX, TX, 0, 115200) 'Cog #8
waitcnt(10_000_000 + cnt) 'wait 1/10 second for serial to start.
ser.char(254) 'Begin marker
ser.str(string("LISTEN:HTTP,/motor")) 'Tell the module to listen to a specific path on http port 80.
ser.char(13) 'End marker
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[2J")) 'Clear putty telnet screen.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[2;3f")) 'Set Position in putty.
ser.str(string("Prop Communication Started")) 'Tell putty command mode is on.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[1;1f")) 'Set Position in putty to put cursor at 0
Repeat 10 ' wait 10 seconds to help determine if motor reset prop.
waitcnt(80_000_000 + cnt) 'wait 1 second
Repeat 'The main repeat loop.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[2J")) 'Clear putty telnet screen.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[2;3f")) 'Set Position in putty.
ser.str(string("Command Mode is On. ")) 'Tell putty command mode is on.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[1;1f")) 'Set Position in putty to put cursor at 0
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[4;3f")) 'Set Position in putty
If ReplyStatus == 1
ser.str(string("Good reply.")) 'If last reply was good, put it back up on putty which was cleared.
Else
ser.str(string(" No reply.")) 'If last reply was bad, put it back up on putty which was cleared.
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[5;3f")) 'Set Position in putty to put cursor at 0
ser.str(string("Speed that the webpage sent: ")) '
ser.dec(Speed)
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[6;3f")) 'Set Position in putty to put cursor at 0
ser.str(string("Current Duty: ")) '
ser.dec(CurrentDuty)
ser.str(string(27)) 'Set ansi command mode in putty.
ser.str(string("[1;1f")) 'Set Position in putty to put cursor at 0
'
ReplyStatus := 0 'Set the reply to bad so it can recheck for a new reply.
Reply[0] := 0 ' clear data
Reply[1] := 0 ' clear data
Reply[2] := 0 ' clear data
Reply[3] := 0 ' clear data
Reply[4] := 0 ' clear data
Reply[5] := 0 ' clear data
Reply[6] := 0 ' clear data
Reply[7] := 0 ' clear data
Repeat 10
ser.rxflush
ser.char(254) 'Begin marker
ser.str(string("POLL:")) 'Tell the module to listen to a ANY protocol/path.
ser.char(13) 'End marker
waitcnt(10_000_000 + cnt) 'Wait for 1/10 s Let buffer fill.
Reply[0] := ser.rxcheck ' should be 254
Reply[1] := ser.rxcheck ' should be =
Reply[2] := ser.rxcheck ' should be P
Reply[3] := ser.rxcheck ' should be ,
Reply[4] := ser.rxcheck ' should be 5 (this could change) The connection identifier to use for this request
Reply[5] := ser.rxcheck ' should be ,
Reply[6] := ser.rxcheck ' should be 1
Reply[7] := ser.rxcheck ' should be 13
If Reply[0] == 254 And Reply[1] == "=" And Reply[2] == "P" And Reply[7] == 13
ReplyStatus := 1 'Set the reply to good so it can be shown in putty.
Handle := Reply[4] 'Store connection identifier.
Reply[0] := 0 ' clear data
Reply[1] := 0 ' clear data
Reply[2] := 0 ' clear data
Reply[3] := 0 ' clear data
Reply[4] := 0 ' clear data
Reply[5] := 0 ' clear data
Reply[6] := 0 ' clear data
Reply[7] := 0 ' clear data
ser.rxflush
ser.char(254) 'Begin marker
ser.str(string("ARG:")) 'Retrieve HTTP GET/POST’s name argument (in query or body) on connection handle.
ser.char(Handle) 'An active connection handle; returned by POLL
ser.str(string(",")) 'Required for a reply
ser.str(string(" Speed ")) 'The argument name to retrieve.
ser.char(13) 'End marker
waitcnt(10_000_000 + cnt) 'Wait for 1/10 s Let buffer fill.
Reply[0] := ser.rxcheck ' should be 254
Reply[1] := ser.rxcheck ' should be =
Reply[2] := ser.rxcheck ' should be S
Reply[3] := ser.rxcheck ' should be ,
Reply[4] := ser.rxcheck ' should be argument value (this could change) -1 no reply
Reply[5] := ser.rxcheck ' should be argument value (this could change) -1 no reply. This could also be 13
Reply[6] := ser.rxcheck ' should be argument value (this could change) -1 no reply. This could also be 13
Reply[7] := ser.rxcheck ' should be 13
If Reply[0] == 254 And Reply[1] == "=" And Reply[2] == "S"
If Reply[5] == 13 'The end marker
Reply[5] := 0 'Zero terminate the string so it can be converted to decimal.
Elseif Reply[6] == 13 'The end marker
Reply[6] := 0 'Zero terminate the string so it can be converted to decimal.
Else 'The end marker all other conditions the end marker is a byte 7
Reply[7] := 0 'Zero terminate the string so it can be converted to decimal.
Speed := ser.StrToBase(@word[@Reply[4]], 10) ' store and convert string angle in byte variable angle.
ser.char(254) 'Begin marker
ser.str(string("REPLY:")) 'Tell the module to send a reply to the poll response.
ser.char(Handle) 'Should be a number. An active connection handle; returned by POLL.
ser.str(string(",")) 'Required for a reply
ser.str(string("200")) 'The desired HTTP response code for the reply.
ser.str(string(",")) 'Required for a reply
ser.str(string("2")) 'Tell the module how many bytes? (or is this digits?) the reply is.
ser.char(13) 'End marker
ser.str(string("OK")) 'Send OK to the webpage.
DAT
Speed byte 0
CurrentDuty byte 0
CurrentSpeed byte 0
ChuffCount long 0
Entry byte 0
WaitTime long 0
Reply byte 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
{{
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// TERMS OF USE: MIT License
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
}}
Well, I drove it down the track, and at 14v, the vdrop over the full wave rectifier was too much, as soon as the motor barely started, the power dropped (due to bad power pickup on the wheels im sure).
So I pushed the voltage up to 18v with the vdrop puts the activity board to 16v, not to mention the increasing drop when the motor starts to pull more current...
That worked, until it reached a switch which I didn't wire properly, hehe, I need to run more feeder wires.
I am not doing dcc yet, thats quite far off in the future, I would need a dcc command station first... (#$%#$%# dont get me started)
I wanted to install a 6800uf capacitor on the 3.3v supply, but I found some of the circuitry on the activity board wx uses 5v (like the a2d chip that I am going to use to monitor the motor current.
So after looking at the circuit, I think I need to use the VIN still, but install some diodes so my 25v 2200uf cap doesn't reverse feed the motor supply (which has its own 6800uf 50v cap).
At this point I am getting a modified circuit that might have unintended consequences, so, it would be wise to finish the schematic to let others here see it and point out where I might go wrong and fry everything.
A wx board, with a wx esp module, and a dual motor board.... it would suck to fry it all.
Indeed it would suck to fry it all, which is why I use optoisolators if that is feasible. I also apply the electronics equivalent of the carpenters rule (measure twice, cut once). The electronic version is a bit more thorough. Double check that every signal and power connection goes where it's supposed to go, and does not go anywhere else before applying power.
Indeed it would suck to fry it all, which is why I use optoisolators if that is feasible. I alsoI apply the electronics equivalent of the carpenters rule (measure twice, cut once). The electronic version is a bit more thorough. Double check that every signal and power connection goes where it's supposed to go, and does not go anywhere else before applying power.
To make things worse, I just added 2 Farad of SUPERCAPS to the 3.3v logic supply! (1amp fuse, 3.3ohm inrush.)
I already blew the 1amp fuses that supply the activity board with power, the super caps must have done it.
I will try adding 1 ohm to the super cap resistance to see if that is enough. Good thing I have a roll of 1amp smt fuses.
The supercaps are no joke.
Nor are the 1amp fast blow fuses, they go AT 1amp, and will not give you any time to dilly-wattle.
Turns out im just a moron (shadup), the barrel plug connectors have the center pin marked, which is positive, I was hooking the power up backwards.
Good thing I had those fuses.
With the supercaps, the power stays on for like 3 seconds after power removal, even WITH the wx wifi, that should help with bad track connections.
Time to put it to test.
I just took the example html code, and searched on how to customize the different elements, like "slider customization" and "check box customization".
Lots of luck, im sure my css has some issues, I do not yet understand how css works, I get html and javascript a bit...
I did need to monitor the TX and RX from/to the prop and the DEBUG port on the WX module with 3 different PropPlugs, to understand what the C code was doing, I am not good at reading C.
I just gotta get that motor current feedback working still, yet another cog gets sucked up..
I will definitely need two props, the sound has now taken a back seat to all the other functions...
I am sure I can combine functions eventually...
The sound isn't that priority because it needs an AMP circuit too.
Who has a 8ohm 25w speaker AMP circuit I can use with the prop? (I have 3.3v, 5v, and 12-14v power available to use, so i can use a regulator also to make 12v, 9v, 6v, etc.)
That thing is a beast! I was hoping for something kinda simple, like opamp, or some transistor pushpull, or the like, even a pre-made pcb on the cheap....etc...
I want to eventually reduce the size of this entire project so it will fit into a HO engine or even a N-scale boxcar...
Heres the working spin code with the index.html and style.css file that it will work with. (the same code I posted above)
I sped up the spin code so it sends data to PUTTY connected to the WX telnet output.
I think it overloads putty, because it will stop receiving the output after a while, I will need to look into why that happens.
Not sure if its putty or if its the WX module.
I cannot include the code in the forum code brackets anymore, its too long.
Zip attached.
The Parallax Serial Terminal cannot communicate faster than 115200, I tried 230400 and the receive data from the WX module fails.
What does the Propeller Activity Board WX REVA have differently than REV B/C?
I cut the chip off, and am ready to solder a new one on, but, i wonder if many of the other chips on this board are dead also now.
I didn't have a TVS installed, because the ones I ordered were the wrong package, and were those super tiny impossible to work with specs of pepper, (literally)
I guess if I get this working again, I won't be doing anything without my TVS's in hand.
Before I cut the chip out, 3.3v was tested as shorted to GND. (typical situation when a prop chip fails)
Now that the chip is cut out, I measure a high resistance between 3.3v and ground. 1759mv.
Revision History
2.0: Updated throughout for hardware Rev B (increased input voltage range and updated wireless
communication and programming functionality. 2.1: changed references to Rev B to Rev B/C which are
electrically identical. See version 1.0 for original Rev A documentation.
Does that mean the motor boards I/O should be opto isolated, I don't have enough room on that breadboard to put that many opto-isolators there.. heh.
I guess I have no other option, either do or die.(again)
I tested the P0 to P15 pins for conduction before cutting the chip out and they all showed the same, around 400mv, so if it was from the motor board, it didn't fry the pin with any indication.
But damn parallax, that xtal so close to the chip, that made this a bit difficult.
I couldn't remove the xtal no matter what I tried.. is that thing superglued down? lol..
(naturally that side is where I accidentally bridged two pins while re-soldering),
I had to fill up all the bridge pins with tons of solder and quickly slam the board on its side which pulled most of it out, but wear saftey glasses if you do this.
Test program uploaded, eeprom uploaded..
Opening file '/NorthwoodsLogger/MotorAndSoundAndWifiControl/RailRoadMotorTestAxleChuff.binary'Downloading file to port COM5
14248 bytes sent
Verifying RAM
Programming EEPROM
Download successful!
Wifi download went ok, so i guess the WX esp board made it through the ordeal.
Opening file '/NorthwoodsLogger/MotorAndSoundAndWifiControl/RailRoadMotorTestAxleChuff.binary'Downloading file to port 192.168.4.1
14248 bytes sent
Verifying RAM
Programming EEPROM
Download successful!
Tough little board, and wifi too. I guess the prop chip isn't so tough...
I wonder if the motor board survived, time to test that.
I can't think of anything that caused this but some high voltage shoot through from the motor board pins.
I wonder if a bunch of 2k + resistors on all motor board pins would be enough, and still let the pwm do its job.
(btw, i have no skill at all... according to SICK INC. in burnsville, mn. But all the green card foreign female workers there have all the skill, thats why I was let go when she returned from vacation after covering for a lady after only 2 weeks while she went on vacation, but yea, go ahead COMPANIES keep on claiming you need those foreign FEMALE workers, that im sure have nothing to do with trafficking at all.)
Usa employment is a terd swirling around the toilet.
Anyway, I do think it was the motor board, what do you guys think?
Anyway, I do think it was the motor board, what do you guys think?
I've used that board with a Propeller Activity Board several times without issue.
I destroyed a Propeller chip using a different motor controller. I posted a photo of my setup and Phil Pilgrim immediately saw my mistake. If you post photos of your wiring, maybe someone here will be able to identify the problem.
You need to make sure the ground connection in your motor circuit is appropriately placed.
Comments
My thoughts...
What is the size of the speaker producing these sounds? IF it is only that tiny thing in the train then high fidelity is wasted.
Playing multiple stored wave files at the same time is problematic. Reading more than one sound at a time means leaping around the ram/rom/SD/ gathering sound bytes fast enough to keep up. Especially considering this storage is serially accessed and all the overhead in changing addresses. However, reducing the data rate and playing in mono would help. 44KHz stereo 16 bit is nearly 1.5 Mb/s (Mega bits per second) or 176 KB/s.
Many years ago I made a 'race announcer and countdown' device to start races in radio controlled model yacht race meetings. I sampled my own voice using a 'BBC Micro' at 10KHz and 8 bit. To my surprise the result was amazingly good! It was better than the telephone audio back then. It replaced a portable tape recorder at the time and everyone agreed it was a big improvement.
Of course I was only playing one sound at a time.
The total storage was 128 Kbytes (less than 13 seconds) stored in eeprom and was easily random accessed quickly.
What is the maximum number of sounds to be played simultaneously?
Hub ram is so small that at even 10KHz 8 bit only a few seconds could be stored.
Can the sounds be broken down into repeated loops?
If you had say six serial roms each with the same sounds on but each being able to be accessed simultaneously, and limiting the simultaneously played sounds to the number of roms, it should be easily doable.
I think with a series of compromises it could be done, but it might take up all the resources of a prop1.
Dave
Record the sounds individually
Use the individual sound files to create an interleaved sound file
Have the individual bits of a "sounds" byte select which bytes from the interleaved file are selected
Sum the selected bytes from the interleaved file and use that sum for the PWM
Doing a lot of the work up front makes accessing and playing the individual sounds a lot faster.
actually it doesn't. At least not with fastspin. A while ago I was able to combine both, but that was for TAQOZ ROM version A. I really would like to try this with TAQOZ reloaded, but could not find out yet how much memory to reserve at the bottom of the HUB. ROM TAQOZ took 64K the newer one seems to need more.
I do not want to bother Peter, he needs to finish P2D2 but maybe you can help me there.
The basic concept is to tell fastspin to compile for code starting at $1000 (old ROM) so it might be $2000 now for TAQOZ (new ROM). I am not sure about the memory map of the current TAQOZ. So the fastspin compiled program starts itself at $1000 ($2000?) in COG1 and jumps COG0 into TAQOZ.
I did some patch for fastspin to automate the process and it was working nicely until Peter and Eric both changed things faster then I was able to follow.
So coexistence is - theoretically - possible and would be a nice way to integrate TAQOZ into spin.
Mike
you've slipped into P2 thinking. The board in question has a P1 so things are different.
Preprocessing the files would certainly save time and RAM at runtime, but then skipping a filesystem and just having raw block based storage for the audio would help too.
Depending on the sample length of the various sounds, it might be possible to keep a clean copy of the chuff and idle sounds (probably the most commonly played) in hub, and then overlay the other sounds into a buffer that is read continuously in a loop by a single PWM cog.
The other sounds could be fetched on demand if necessary, and summed into the buffer. Then on completion of that sound combination simply copy the clean loop back into the output buffer.
Of course the transitions from single sounds to multiple sounds might not sound very good if using precombined sound files.
That IS one way to to do it. Multiple sounds mixed on the left channel, and other sounds mixed on the right, and mute/unmute/load the proper mix combinations...
But the timing would be kinda locked together....
I will need to think about that, and write a matrix of sound combinations with sound lengths and see if it will work.
I think I may AT LEAST need 4 channels of audio. (so 2 stereo files)
That still means two stereo files playing back simultaneously.
I wouldn't have a problem combining TWO propeller chips, or three, or four..
Technically if I have two prop chips, one that does everything, and the other that does all the sound....
I could connect 3 or 4 sd cards to the second sound prop chip and run multiple sound cogs that each access their own sd card independently on different pins with different audio out pins, which are combined externally......
HMMMM
At least for G-scale engines, plenty of room.
I did multiple props with my blackbox, one can clock the other to stay in perfect sync.... etc... I was able to fit all the code on one eeprom, one xtal, and have one prop program all the others, and output the 5mhz clocks.
You can see the eeprom (smt) and the socket for the prop plug at the very bottom center prop.
Hi Mike
as @AJL said - we are on P1 here.
@"Clock Loop"
when you talk about using more HW, multiple props, ... etc.
Then maybe think about it.
You can stick with your existing SW and compensate limitations of the language/environment (SPIN) with HW.
@"Clock Loop"
OR you could do a stretch / leap jump and go for Tachyon with just one P1.
I want to give some numbers to Peter's proposal of merging several sound files realtime with Tachyon.
Looking at EASYFILE he states
so thats 512kByte/s
a 8 bit mono at 10kHz is just 80kB/s
so you can do 6*80 = 480kB/s
(you really need 6 sounds overlapped?)
IF you store the sound files UNFRAGMENTED on SD so they can be read in sequence without FS overhead.
Standard in EASYFILE are 4 file handles with 4 file buffers.
But with little tricks you can just use those file buffers for the data handling
In a loop a sector of each file is read alternating into the always same buffers 1&2
A second COG can do the combination into one of the buffers #3/#4,
like adding them up and doing some normalization. 2 = rsh 1, 4 = rsh 2
Don't know if an extra COG would probably be used to feed the data out to the pin - or a 10kHz 'interrupt' could do this.
if two combination buffers (#3/#4) are used alternating
calculating one and playing the other then there won't be any switch over lag
Sound combination could only be started at buffer borders (160 times / second) - noone will realize this ;-)
The other functions I have seen you talking about should be really easy with all the tools in EXTEND.
Like PWM, sensor readings, blinking LEDs, SPI, I2C ... all without any additional libraries
Of course - changing horses during the race ... - but sometimes makes sense, when one horse can't run any more.
And you can get a young and strong one ...
Of course I know and like Tachyon and I am a bit biased ... ;-)
but there was a time ... when I had no idea about Forth and Tachyon ....
so it is possible to learn it
AND it is fun
wow - what a board ...
you know those? - simple 3-pin SPI
https://www.aliexpress.com/item/4000159117591.html?spm=a2g0o.productlist.0.0.bcfa5d7dgtRNsa&algo_pvid=622d305a-dcb1-48bf-90db-3123d3d23e82&algo_expid=622d305a-dcb1-48bf-90db-3123d3d23e82-18&btsid=0b8b036d15993981684372861ee141&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_
or
https://www.aliexpress.com/item/32838376871.html?spm=a2g0o.productlist.0.0.e0263e37z72KxI&algo_pvid=91fd6df1-ad80-49e1-9ead-d741d4724287&algo_expid=91fd6df1-ad80-49e1-9ead-d741d4724287-49&btsid=0b8b036315993985273281297e54f3&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_
I am slowly understanding how to talk to the wifi WX module IN SPIN, and so far so good, all the examples are in C, but soon, my examples will be here, in SPIN.
I am hoping to do this in prop spin with objects in the GITobexHUB, and then once I have a working setup, moving my train, possibly with a second prop doing the sound, ,....(unless someone can barf some code up to make it happen on the first prop)
Then I will start to look what it will take and what can be done with a P2. Hoping that many GITobexHUB objects will be created by that time...
Not sure if you know it, but that black box sequencer/synth is SUPPOSED to be large and gawdy, the row of LEDS light up, and are the actual buttons also. IT OUTPUTS SPDIF DIGITAL AUDIO or regular analog... It can be connected to as many other black boxes as the user creates.... Yes, LEDS as buttons, thats why they are glowing, there is a CCFL tube mounted on the other side above the leds, (that image is the backside) It was a labor of love to put into practice the ability to use a LED as a sensor (a tribute to forrest mims), so is the Mims Mirror.
https://hackaday.io/project/16788-mimsmirror
I had no desire to make it small, or do it on a 'TM1638' !
Im a parallaxian!
Fellow parallaxians, unite and SPIN!
ok then - of course you can use SPIN and as many props as you like ...
no more suggestions for less Props and Tachyon from my side
but I will watch your progress ;-)
So my spin code to get the webpage control working has slowed to a crawl.
Here is WORKING! spin code to poll a webpage for an event.
And here is the webpage to upload to your module to send the event.
https://github.com/parallaxinc/propeller/blob/master/libraries/community/p1/All/WX ESP8266 SPIN Get Started/val-from-micro.html
The module will reply with a POLL answer of " Reply: '=G,5,1' " But you can only see this reply if you view the DBG pin on the WX module in 115200.
(or parse the return data to the prop)
The code just puts the WX module in to command mode, sets up a listener, and polls for the webpage's request,
it does not send the reply to the webpage, and then it just exits command mode. So a number will NOT show up in the webpage box.
If it doesn't then it will send "Bad Reply".
It also sends the data with the reply, which will show up in the box on the webpage.
Which will be the number of loops the code runs through, up to 254 then will roll over to 0.
This program will WORK with the html webpage located here.
https://github.com/parallaxinc/propeller/blob/master/libraries/community/p1/All/WX ESP8266 SPIN Get Started/val-from-micro.html
Time to code the engine control.
So I pushed the voltage up to 18v with the vdrop puts the activity board to 16v, not to mention the increasing drop when the motor starts to pull more current...
That worked, until it reached a switch which I didn't wire properly, hehe, I need to run more feeder wires.
I am not doing dcc yet, thats quite far off in the future, I would need a dcc command station first... (#$%#$%# dont get me started)
I wanted to install a 6800uf capacitor on the 3.3v supply, but I found some of the circuitry on the activity board wx uses 5v (like the a2d chip that I am going to use to monitor the motor current.
So after looking at the circuit, I think I need to use the VIN still, but install some diodes so my 25v 2200uf cap doesn't reverse feed the motor supply (which has its own 6800uf 50v cap).
At this point I am getting a modified circuit that might have unintended consequences, so, it would be wise to finish the schematic to let others here see it and point out where I might go wrong and fry everything.
A wx board, with a wx esp module, and a dual motor board.... it would suck to fry it all.
Heres some crappy code that I am using to run it all.
The sound parts and the chuff sensor were disabled because I am using too many cogs (its the sound doing it, due to using up to 3 or more cogs i think, the waves don't block so multiple waves try to start, i dunno.
All the more reason to do the sound with another prop, unless someone comes up with a multi wave player (but the sd access is an issue?)
Again, another reason to do the sound on another prop with multiple sd cards and multiple sound engine outputs that mix externally.
Heres some garbage code that does work.
Ohhh, shiney colors...
Its now on the first post for ease of maintenance.
Indeed it would suck to fry it all, which is why I use optoisolators if that is feasible. I also apply the electronics equivalent of the carpenters rule (measure twice, cut once). The electronic version is a bit more thorough. Double check that every signal and power connection goes where it's supposed to go, and does not go anywhere else before applying power.
EDIT spelling error
To make things worse, I just added 2 Farad of SUPERCAPS to the 3.3v logic supply! (1amp fuse, 3.3ohm inrush.)
FRY BABY FRY!!!! lol.
I also need to add some TVS diodes....
I will try adding 1 ohm to the super cap resistance to see if that is enough. Good thing I have a roll of 1amp smt fuses.
The supercaps are no joke.
Nor are the 1amp fast blow fuses, they go AT 1amp, and will not give you any time to dilly-wattle.
Turns out im just a moron (shadup), the barrel plug connectors have the center pin marked, which is positive, I was hooking the power up backwards.
Good thing I had those fuses.
With the supercaps, the power stays on for like 3 seconds after power removal, even WITH the wx wifi, that should help with bad track connections.
Time to put it to test.
The spin code is not done yet...
style.CSS
NOT BAD? This looks great! What a creative and interesting project.
Thanks for sharing this.
Thank you!
I couldn't have done it without the many examples on how to use the parallax WX wifi module here:
https://learn.parallax.com/tutorials/language/propeller-c/parallax-wx-wi-fi-module-prop-c
I just took the example html code, and searched on how to customize the different elements, like "slider customization" and "check box customization".
Lots of luck, im sure my css has some issues, I do not yet understand how css works, I get html and javascript a bit...
I did need to monitor the TX and RX from/to the prop and the DEBUG port on the WX module with 3 different PropPlugs, to understand what the C code was doing, I am not good at reading C.
I am glad I did the servo control SPIN code, because I will be using a parallax standard servo to control RR CROSSING ARMS! (so fun!)
Servo WX spin code--> https://forums.parallax.com/discussion/comment/1506197/#Comment_1506197
I just gotta get that motor current feedback working still, yet another cog gets sucked up..
I will definitely need two props, the sound has now taken a back seat to all the other functions...
I am sure I can combine functions eventually...
The sound isn't that priority because it needs an AMP circuit too.
Who has a 8ohm 25w speaker AMP circuit I can use with the prop? (I have 3.3v, 5v, and 12-14v power available to use, so i can use a regulator also to make 12v, 9v, 6v, etc.)
Your awesome project deserves something in the same grade of excellence.
That thing is a beast! I was hoping for something kinda simple, like opamp, or some transistor pushpull, or the like, even a pre-made pcb on the cheap....etc...
I want to eventually reduce the size of this entire project so it will fit into a HO engine or even a N-scale boxcar...
Heres the working spin code with the index.html and style.css file that it will work with. (the same code I posted above)
I sped up the spin code so it sends data to PUTTY connected to the WX telnet output.
I think it overloads putty, because it will stop receiving the output after a while, I will need to look into why that happens.
Not sure if its putty or if its the WX module.
I cannot include the code in the forum code brackets anymore, its too long.
Zip attached.
The Parallax Serial Terminal cannot communicate faster than 115200, I tried 230400 and the receive data from the WX module fails.
The prop chip on the activity board has officially fried.
I did not change anything when it happened.
First thing was the ground fuse fried, but not the v+ fuse.
Then I replaced the fuse, and the propchip is super hot now.
THE
END.
(I can replace the chip, but why, if i do not know why it failed...)
Look at the schematic, and please, start suggesting.
I cut the chip off, and am ready to solder a new one on, but, i wonder if many of the other chips on this board are dead also now.
I didn't have a TVS installed, because the ones I ordered were the wrong package, and were those super tiny impossible to work with specs of pepper, (literally)
I guess if I get this working again, I won't be doing anything without my TVS's in hand.
Before I cut the chip out, 3.3v was tested as shorted to GND. (typical situation when a prop chip fails)
Now that the chip is cut out, I measure a high resistance between 3.3v and ground. 1759mv.
2.0: Updated throughout for hardware Rev B (increased input voltage range and updated wireless
communication and programming functionality. 2.1: changed references to Rev B to Rev B/C which are
electrically identical. See version 1.0 for original Rev A documentation.
Sorry to hear that.
Time to put a new prop on.
I suspect the motor board allowed a high voltage to shoot through to the prop pins somehow.
https://www.parallax.com/product/28820
Does that mean the motor boards I/O should be opto isolated, I don't have enough room on that breadboard to put that many opto-isolators there.. heh.
I guess I have no other option, either do or die.(again)
I tested the P0 to P15 pins for conduction before cutting the chip out and they all showed the same, around 400mv, so if it was from the motor board, it didn't fry the pin with any indication.
But damn parallax, that xtal so close to the chip, that made this a bit difficult.
I couldn't remove the xtal no matter what I tried.. is that thing superglued down? lol..
(naturally that side is where I accidentally bridged two pins while re-soldering),
I had to fill up all the bridge pins with tons of solder and quickly slam the board on its side which pulled most of it out, but wear saftey glasses if you do this.
Test program uploaded, eeprom uploaded..
Wifi download went ok, so i guess the WX esp board made it through the ordeal.
Tough little board, and wifi too. I guess the prop chip isn't so tough...
I wonder if the motor board survived, time to test that.
I can't think of anything that caused this but some high voltage shoot through from the motor board pins.
I wonder if a bunch of 2k + resistors on all motor board pins would be enough, and still let the pwm do its job.
(btw, i have no skill at all... according to SICK INC. in burnsville, mn. But all the green card foreign female workers there have all the skill, thats why I was let go when she returned from vacation after covering for a lady after only 2 weeks while she went on vacation, but yea, go ahead COMPANIES keep on claiming you need those foreign FEMALE workers, that im sure have nothing to do with trafficking at all.)
Usa employment is a terd swirling around the toilet.
Anyway, I do think it was the motor board, what do you guys think?
I've used that board with a Propeller Activity Board several times without issue.
I destroyed a Propeller chip using a different motor controller. I posted a photo of my setup and Phil Pilgrim immediately saw my mistake. If you post photos of your wiring, maybe someone here will be able to identify the problem.
You need to make sure the ground connection in your motor circuit is appropriately placed.
Im still convinced its the motor board.
If I need to use opto isolators on all the motor pins, I will need this larger breadboard, lol, but that won't fit in my tender...
....
..