Thread Tools
Mar 02, 2013, 05:42 PM
Registered User
Dutchraptor's Avatar
OK, I'll take out the breadboard again and cook up a new shield/board for the nano. How many sounds? Prepare it for 32 sounds, 2 engines and 1 volume control? That way we can build the version with the basic sounds we install. The other soundbits can be filled with just the soundnumbers so people can change them themselves. All pins will have a pull-down so there won't be any ghost signals. The receiver input shall also get two pots each for setting high and low values, all transmitters have different values in my experience.

My serial number proposel is:
1000-1255 for input engine1
1500-1755 for input engine2
2000-2255 for volume control
2500-2755 for pin group1 (8 pins from PCF8574P/nr.1)
3000-3255 for pin group2 (8 pins from PCF8574P/nr.2)
3500-3755 for pin group3 (8 pins from PCF8574AP/nr.1)
4000-4255 for pin group4 (8 pins from PCF8574AP/nr.2)

If needed, we can easily add more. I shall look at the menu version tomorrow morning, it's 00:42 here (just got home from work).

Sign up now
to remove ads between posts
Mar 02, 2013, 05:51 PM
blutoh's Avatar
Wait. Won't it work with the existing design you already have (mega?)? I don't want to add unnecessary .hardware. Lets review it before we change direction. Go get some sleep now. Then we'll look at it with fresh eyes .

Mar 02, 2013, 06:26 PM
Registered User
Dutchraptor's Avatar
A few little adjustments to the transmitter shield and all pins can be used. That would give total of 70 pins. 2 of those for revs, 1 volume, 4 for ranges, 2 for receiver input, 1 for selection serial/conventional, a few as backup pins for whatever. A fresh eye would help. But a quick count gives apart from the above summary about 54 soundbits . That's all of the digital pins together.

BTW: a little led telling the Rasppi is booted up, isn't a luxery. 30 seconds can be long when your waiting.

Good idea, now I go to bed, long day tomorrow.

Last edited by Dutchraptor; Mar 02, 2013 at 06:33 PM.
Mar 03, 2013, 01:05 AM
Registered User
tweety777's Avatar
Originally Posted by blutoh View Post

Well Enhancer definitely needs this sound system. It's surprising how much realism a sound system adds. And we need your feedback. We get a lot of views on this thread, but very little comments. So download it and give it a try, we want to hear what you, and anyone else, have to say about it.

In that case I'll certainly give it a try.
Though I must admit that it is thanks to Danny that I'm already this far, programming is not (yet) my strong point, it's getting a little better, but to me it's still not so much fun as building the boat and working with electronics.
On the other hand, working with electronics might well be due to my grandfather (who passed away years ago, so no help there...) and my father is really into programming so I might well see the light someday, probably first need to understand the language quite a bit better...

Greetings Josse
Mar 03, 2013, 03:02 AM
Registered User
Dutchraptor's Avatar
It's not only programming that helps Pete (and myself). People with no experience are also needed so we can test if it really is universal. People with some experience will work around problems and adjust the system to their needs. We need input from others so the system can develop to what the community wants not just what Pete (or Pete and I) want. Programming is nice, but yes,a bit harder. Ideas are easier and if it can be done, they can be implemented or discussed.

Mar 03, 2013, 11:41 AM
blutoh's Avatar

Thinking out loud. Maybe we should pass the message from the arduino to the raspi, exactly as it comes from the transmitter, then decode and process on the raspi? The raspi would only respond to messages that require sound effects and discard the rest. The arduino would continue to process the message as usual. This would reduce the # of pins consumed. Do you have a record layout for the message content?

Mar 03, 2013, 05:20 PM
Registered User
Dutchraptor's Avatar
I think you're going to need this. I'm thinking that with defines we can choose which command is send to the rasppi and which not. Or we can let that do the rasppi since it has more calculation power. The Arduino only sends the command and goes on with it's own functionality. A config part in the rasppi code can then sort out which sound is heard and which are not used.

grtz Danny

EDIT: but we still need to make a version for non-arduinocontrol users.

Functional group 1:
servo 1 - 11000->11500
servo 2 - 11500->12000
servo 3 - 12000->12500
servo 4 - 12500->13000
servo 5 - 13500->14000
servo 6 - 14000->14500
servo 7 not used
servo 8 not used
servo 9 - 15000->15500
servo10 - 15500->16000
servo11 - 16000->16500
servo12 - 16500->17000

Functional group 2:
pin 22 -> 21128
pin 23 -> 21064
pin 24 -> 21032
pin 25 -> 21016
pin 26 -> 21008
pin 27 -> 21004
pin 28 -> 21002
pin 29 -> 21628 (21500+128)
pin 30 -> 21564
pin 31 -> 21532
pin 32 -> 21516
pin 33 -> 21508
pin 34 -> 21504
pin 35 -> 21502
pin 36 -> 22128
pin 37 -> 22064
pin 38 -> 22032
pin 39 -> 22016
pin 40 -> 22008
pin 41 -> 22004
pin 42 -> 22002
pin 43 -> 22628
pin 44 -> 22564
pin 45 -> 22532
pin 46 -> 22516
pin 47 -> 22508
pin 48 -> 22504
pin 49 -> 22502
PinA14 -> 23128 => rerouted to pin A6 
PinA13 -> 23064 => rerouted to pin A5
PinA12 -> 23032 => rerouted to pin A4
PinA11 -> 23016 => rerouted to pin A3
PinA10 -> 23008 => rerouted to pin A2
PinA09 -> 23004 => rerouted to pin A1
PinA08 -> 23002 => rerouted to pin A0
PinA15 -> 23628 => rerouted to pin A7
Last edited by Dutchraptor; Mar 03, 2013 at 06:44 PM.
Mar 03, 2013, 08:12 PM
blutoh's Avatar
Originally Posted by Dutchraptor View Post
....... Or we can let that do the rasppi since it has more calculation power. The Arduino only sends the command and goes on with it's own functionality. A config part in the rasppi code can then sort out which sound is heard and which are not used.......
Exactly. For example, I see that 21128 translates to group 2 with an 8 bit value of 128 or "pin 22". Then in the sound effects code we would maintain a translation table, to know which value corresponds to which sound, and process accordingly. This transfers some of the processing burden to raspi. Does this approach make sense?

Originally Posted by Dutchraptor View Post
EDIT: but we still need to make a version for non-arduinocontrol users.
Right, but we need to wait and see what method will be used by other systems to send the message, and what that message content will be. It could be anything from a multiswitch, which limits funtionality to on/off, or maybe a small microcontroller that reads and forwards PCM throttle stick info to the raspi, like a nano, or maybe a PICAXE? Right now thats all speculation and requires more research, hopefully someone will come forward and participate on that piece (hint!). The only known scenario we have is your arduino control system, so we should continue forward with that as our basis. When we have more info about other interfaces, we can proceed on them, too.

Last edited by blutoh; Mar 03, 2013 at 08:53 PM.
Mar 04, 2013, 03:08 AM
Registered User
Dutchraptor's Avatar
A simplified version of the arduino stripper would be:
- check if the first character is '2' (it can be any number or character)
- if it is, process this group
- convert to int (numbers instead of asci)
- read from the number character till the fourth character
- if the value is between 1000 and 1500 then:
- if the value equals 0 then turn off all pins in this subgroup (22->28)
- if value is higher then or equal to 128 -> activated pin 22
- substract 128 from value
- if value is higher then or equal to 64-> activated pin 23
- substract 64 from value
- if value is higher then or equal to 32 -> activated pin 24
- substract 32 from value
- if value is higher then or equal to 16 -> activated pin 25
- substract 16from value
- if value is higher then or equal to 8 -> activated pin 26
- substract 8 from value
- if value is higher then or equal to 4-> activated pin 27
- substract 4 from value
- if value is higher then or equal to 2-> activated pin 28
- substract 2 from value

As you can see, I don't use 1. I've had some problems sending just a 1 code. One day I will find out why, but it doesn't bother me enough to check. I my serial version I already made a conversion from character to number. You can also change the whole code to a number and first make a check if the codenumber is between 20000 and 29999 before entering a subgroup. I choose not to so I could also use letters and other characters (from my older protocol). By using this 8-bit count I can create any number between 0 and 255 and thus exactly find out which pin are on/off. The transmitter does it the other way round, it just adds (2/4/8/16/32/64/128). This way I don't have to send a seperate on and off code. Just 1 code for 7 functions.

Last edited by Dutchraptor; Mar 04, 2013 at 03:18 AM.
Mar 04, 2013, 09:33 AM
blutoh's Avatar

OK so a few questions come to mind:
If the throttle stick position changes, what happens to pin # value? I need to know when to move the engine rpm sound up or down. What are you doing in the receiver code to address that and change speed?

In the raspi code I need to map pin / values to functions, currently we have this:
128 = engStart
64 = engStop
32 = ambient sound toggle on/off
16 = foghorn
8 = horn
4 = whistle
2 = unassigned
1 = quit

What about values between 008 <-> 016, 016<->032 etc.? Are you ever passing these values? I still need to add winches, crane sounds and other effects. So if these are not utlized, then my idea is to process the entire value passed in to the program, including the group #. This way I can map more sounds and functions.

Mar 04, 2013, 11:41 AM
Registered User
Dutchraptor's Avatar
Let me clearify:
lets say pin 22 and 25 are active: the code will be 128 + 16 = 144.
23 and 27 and 28 => 64+4+2 = 70.

The receiver side substracts and switches the pin on or off follwing the process as descriped. That's the mystery of the missing numbers. That way I can send several pin in 1 go.

Last edited by Dutchraptor; Mar 04, 2013 at 01:19 PM. Reason: typo error
Mar 04, 2013, 03:15 PM
blutoh's Avatar

OK, thanks. I now have that all coded in a testing program. Next is engine rpm. I see from your post #67 the servo values. As an example, lets assume that servo 2 is the throttle servo. Your chart shows this range of values for servo 2:
servo 2 - 11500->12000
What messsage and value will you pass to the sound system? Will it be a value between 11500-12000? If so I can carve it up into ranges and adjust the engine rpm sound based on the range. If not, let me know what message or values you can send.

Mar 04, 2013, 03:30 PM
Registered User
Dutchraptor's Avatar
I can't think of a better way to explain to a programmer, then this way
if (value >= 11500 && value <=12000){ // is it the servo or something else
value = value -11500; // get the raw send value 1-255
value = map(value, 255,0,-9,9); // remap value from 0->255 to -9 to 9 (0 middle)
if (value < 0){value = value * -1;} // make negative value positive
play sound value // this is where your code comes in.

The raw value from the transmitter is for example 11645. If you substract 11500 you get 145 as value for the servo/speedcontroller setting. The servo range is from 0 to 255 with 128 as the middle point. By mapping the value from -9 to 9 you get the 128 as 0 (idle). When revving up the value increases and is remapped from 1 to 9. If reversing then the vale become negative. By multiplying it with -1 you make the mapped value positive again and thus you can recyle the sounds again only now for reversing.

Hope it makes sense.

Mar 04, 2013, 03:37 PM
blutoh's Avatar
OK, no problem. Was my assumption correct, servo 2 is the throttle, or is it a different servo?
Mar 04, 2013, 03:57 PM
Registered User
Dutchraptor's Avatar
Totally free to assign. It doesn't matter to which pins I connect the pot for the motors. The first 4 pots/channels are send continously (faster update and no hysteresis for sending), the rest of the commands are only send when the value changes (the pots have a small hysteresis to filter very little changes). I'm busy building the transmitter side again. This time with a very neat little PCB instead of the spiderweb. The PCB is build, the pots are connected and the pins are tested. Tomorrow I going to make the Switch PCB's and I hope the Channel Selection PCB (new one with RotaryEncoder (the other one was a modified version of the old channelselecter with encoder)). After that, the test versions/proof of concepts are finished and I can start rebuilding the real transmitter. It's much easier working/experimenting outside the transmitterbox or boat.


Thread Tools