the DCC on a budget workbench.

[Sean]

Ya but can your loksound do this??

 

 

IE familliarity and training day on the new Caribbean prime movers

 

The stay alive capacitor is going to be 100% needed so not gonna post up any diagrams or parts lists until I find out how they fit into this..... I have no diodes so unless I can find a nice circuit without one I'm snared until I order more bits. There seems to be a few at least so I may experiment.

 

That's definitely the hardest part sussed 

[Sean]

so here we go again.

Admittedly the train to skaville soon blew up due to a myriad of issues with the design. I'll discuss just WHY when I give an overview soon, all issues came down to trying to run a 6 watt amp with a rather underpowered 5v converter and windows insisting on 100% volume everytime the Bluetooth clicked off and back on and trying to have a stay alive with no diodes.

It worked for about an hour before going kaput

However now impressed with the tech I'm after spending a few Bob on components  that should bring the desired outcome with all of my locos. New soldering iron,, glue gun the lot.

Will update soon with hopefully a working loco.

Edited April 6, 2022 by Sean

[murphaph]

Very much looking forward to following your progress!

[Sean]

when you extract the wavs from the MM201 .ESU file for a closer look........

 

 

 

[Sean]

Drive hold working on a lokpilot with a JMRI virtual sound decoder! not the best of videos but you get the idea.

 

note that the function is tied to the headlight for testing purposes.

 

@murphaphit seems that drivehold is actually a feature of the lokpilot as well as the loksound. when i did a bit of digging into the logical functions in decoderpro i was greeted with these options so theres a bit more under the hood than we think in these lower end chips, no reason it shouldnt also work on nextgen too as its actually seperate to the sound suite and works just the same as if there was no sound at all.

 

the 201 is also done and works although its not perfect and i really needed to take some time away from it before getting back to it as the keep alive was a bit of a head melter. will upload a video of that soon i still need a windows pc to run nextgen on so im at the mercy of whenever i can borrow the laptop again. rocrail and nextgen wont  run on the same pc either(bug)so that adds even more complexity lol. (im considering using some virtual machines but thats getting super advanced.)

 

at this point im not sure if ill use rocrail or JMRI both currently have their pitfalls and neither are easily allowing me to stream audio to multiple different outputs. nextgen seems to be way better than the jmri solution however on the flip side rocrail is not the most stable using my setup as there are a lot of moving parts and the arduino itself crashes regularly. nexgen within JMRI would be the stuff of dreams although i dont think that is possible at the moment. im maybe a little tempted to get the cheapest z21 i can get my hands on to run nextgen this way but i am a big fan of JMRI so we shall see. porting prime mover sounds into JMRI seems to be a fairly trivial process once i have decent source files ready to go. perhaps someone on the JMRI community would be interested in modifying the sound decoder for multiple outs. in my head it would be easy but i dont know a line of java lol.

 

all that being said im still running everything off the linux netbook so i need to get around to building a proper pc for this soon anyway from the parts pile. all in good time though.

 

 

 

 

 

 

[murphaph]

Interesting Sean. I guess that makes sense as the LP is designed to work in tandem with the LS (for example in a double header setup). It's good to know it works though. I'm hoping NextGen is further developed and possibly integrated into Rocrail though the dependency on dlls makes that unlikely I reckon. I don't think Rob Versluis (not sure on the spelling) would be too keen on the Windows reliance for any part of Rocrail.

[Sean]

if the developer of nextgen used literally any other protocol except for z21 this would be a lot easier for jmri lol.

 

is it normal to only use a single sound decoder when consisting? obviously itd save 100 quid  but i feel like a certain characteristic  of hearing 2 engines running together would be lost with only one speaker/engine.

 

edit: JMRI does actually list multimaus as supported so maybe i simply need to look a little closer. edit2:my z21 app is now connecting to jmri but nothing works yet, this is very promising.

Edited April 21, 2022 by Sean

[murphaph]

I think a lot of people use 1 sound decoder when double heading just to keep the costs down. I guess 2 would be better but ESU in fairness realised that the cost would be prohibitive for many, especially US modellers where you could have 4 or 5 locos in consist. The sound decoders would double the cost of your locos over there in most cases. If you do run two locos in consist with sound decoders or bluetooth sound, the sound files should be slightly modified so that the prime mover frequencies are not identical. You get weird phasing if they are both the exact same.

If I had to choose between cheap sound and Rocrail (which supports hardware offering the opendcc bidib protocol, which is more important to me than sound) I would choose Rocrail but I'm optimistic the NextGen stuff will be further developed. It's "European" in origin and is reasonably likely to see requests to better integrate it with Rocrail, JMRI being more popular in Anglo-Saxon countries, especially North America. You can see that with bidib support in Rocrail. Funnily enough I just went looking and bidib support is being added to JMRI but it's only available in a development branch, it hasn't been merged with the main branch yet:

https://forum.opendcc.de/viewtopic.php?t=6879 (sorry it's all in German)

I think I'll wait until it's stable and included in JMRI before I bother with it though. Nice to have an alternative to Rocrail some day though.

[Sean]

I dont think you would have much of a problem with destructive phasing as the engine tone oscillates rather than sitting at one specific frequency. the sound of the 2 prime movers would not be in sync if the motors started at different times also so the 2 sources should harmonise into one perceptually. any losses in fidelity due to phase would probably only apply if sitting in between the 2 speakers however these losses would also be experienced in the real world also, particularly if walking around 2 large running prime movers, you will always hear some audible anomalies between the 2 engines.

 

issues with phase in the real world in my experience has mostly been confined to recording with a stereo pair of microphones or in large line array PA systems in large venues where the sound has to actually travel a distance before it gets to the audience who will be hearing the performance from multiple sound sources and phase or delay can occur due to the same sound reaching them at different times from different speakers.

 

it is not something i had ever considered in speaker design all that much before seeing it demonstrated on that video a few weeks ago with the train speaker although even then i found its importance to be limited as the guy took care of it quite easily and designing any sort of speaker cabinet at all really tends to seperate the front and back of the cone, with the back sound being completley different once it finally bounces around and gets out the port on the back of the speaker.

 

you see thats the thing. my hardware (dccpp) runs under both however the rocrail version seems very buggy and the command station routinely crashes leaving a loco running with throttle applied until rocrail is restarted which leaves me stuck on JMRI as that is going to cause an expensive accident on my end to end before long and with the prices of this rolling stock that will make me very sad.

 

when my next paycheck arrives im very tempted to just order the z21 multimaus off ebay de and run nextgen via that, i genuinely dont think the nextgen dev has intended for jmri or rr compatibility it just so happens to be a bonus that they do work, the fact that my z21 protocol apps are connecting to jmri but not sending or recieving throttle commands has me optimistic too, theres a few different z21 protocols available with jmri depending on the age of said z21 equipment so it may still be down to giving it a bit of a tweak till it works, sadly there is no jmri forum to ask one and the documentation is a bit sparse

 

[murphaph]

Interesting but I experienced what I thought was phasing when running two 121s in consist with the same sound file. The sound almost vanished completely at times. It was very odd. They probably did start at exactly the same time as they were set up as a consist however.

[Sean]

in my mind the sounds would sum and be too insignificant to cause any sort of perceptible phasing, however it wouldnt surprise me either, perhaps it might come down to the sound getting thrown everywhere without any sort of enclosure as opposed to it being more directional if coming from an enclosure.

 

yep had a think about that, even if you started the engines seperately as soon as you notch the engine the next set of wavs are going to be triggered at the exact same time bringing it all into sync, altering the wavs of one loco to loop in at a different point would solve that but it still wouldnt be entirely realistic as the 2 engines would ALWAYS still be exactly in sync just firing at different points.  in real life no 2 engines can be exactly the same off the factory floor and that becomes even more apparent as components wear and they will run at marginally different rpm's and the sound will overlap in and out of itself. particularly as rpm changes.  theres a certain randomness in timbre between 2 running motors that would just be difficult to fully capture within a piece of software looping wavs on cue.

 

you would nearly want to have 2 entirely different recordings of the same prime mover type and somehow randomly delay one of them by a random 1-100ms interval at a notch change,  I dont know if ESU even know how to do stuff like that yet lol. a DAW on the pc could do it with nextgen running but feck thats even more moving parts that im not going to even consider investigating 

my thinking was i could have 2 nextgen files running to a single bluetooth module in mono with a mover panned to each speaker and a speaker in each logo. no good unless all the above aforementioned stuff is first solved.

Edited April 21, 2022 by Sean

[murphaph]

In the Lokprogrammer there's an option to alter the frequency of the prime mover on a given decoder using the same sound file. I read somewhere that it's for cases like this where running in consists produces weird sounds unless you do that.

[Sean]

ah sweet, one of the easiest forms of pitch shifting is a slight change of tempo, which would translate to a slight change in rpm for our uses. that would both solve the issue of possible cancellation and create the slight rpm overlap i mentioned earlier.(think like between 1-10rpm of a difference. minute stuff mechanically but enough for the ear to pick up on)

 

You are after getting me very curious about this now and im after finding somthing in the manual that MIGHT just explain it. as the speakers arent usually marked it could be easily overlooked.

 

this makes the most sense to me as if the speakers were wired with opposing polarity one is creating a positive pressure wave whilst the other is creating a negative one and vice versa. as the sound waves are identical this is where we would see phase related issues crop up and cancellation would be most apparent when both speakers are equidistant from the listeners ear, but less apparent if heard side on

it works the same when recording a snare drum for example in a recording studio with a microphone set on the top and bottom of the snare, as the micrphones are facing one another we get the same phenomena of one mic recording a positive wave whilst the other one records the negative wave, usually theres a button on the console or within the recording software itself to reverse the polarity or else the waveform can be later flipped in software.

its also important to measure the distance from the microphone to the drum head as the sound has to reach both micrphones at an identical time or else a slight audible delay is recorded and phase flipping will not work.

 

 

Edited April 22, 2022 by Sean

[irishthump]

8 hours ago, murphaph said:

In the Lokprogrammer there's an option to alter the frequency of the prime mover on a given decoder using the same sound file. I read somewhere that it's for cases like this where running in consists produces weird sounds unless you do that.

When you open the Lokprogrammer software it's on the "Decoder" sidebar under "Sound Slot Settings". You adjust the maximum and minimum speed for each sound slot using the sliders. It's best to decrease the minimum speed and increase the maximum speed by a couple of percent on one of the locos you are double-heading. You ccan also alter the pitch of horn sounds to make them sound more "Irish" if you like.

20 hours ago, murphaph said:

Interesting but I experienced what I thought was phasing when running two 121s in consist with the same sound file. The sound almost vanished completely at times. It was very odd. They probably did start at exactly the same time as they were set up as a consist however.

Yes I've experienced phasing when running consists, the most noticeable being in a Bachmann A/B F-Unit set with both units having the same Soundtraxx decoders and speaker set ups. Like you noticed it's not a constant thing but comes and goes depending on the pitch of the sound and the distance you're listening from. I've also noticed it in consists of 141/121 locos when using the same sound file. It can be more pronounced when the speakers are close together which can happen considering how they are positioned towards the end of the loco.

On 21/4/2022 at 8:48 AM, murphaph said:

I think a lot of people use 1 sound decoder when double heading just to keep the costs down. I guess 2 would be better but ESU in fairness realised that the cost would be prohibitive for many, especially US modellers where you could have 4 or 5 locos in consist. 

 

I have done this with some US locos. I turned the B Unit in a A/B set of F3's into a dummy unit by removing the motor and drive train. I also wired a second speaker into the B Unit to run of the same decoder. What many don't realize  is you can actually fit 2 prime mover sounds on one decoder. It doesnt sound as good as having 2 separate decoders but it's a cheaper alternative.

Edited April 22, 2022 by irishthump

[Sean]

Spent a good few hours trying to make rocrail and jmri talk to eachother via loconet or some other protocol with the thinking jmri could be a stable base station and rocrail could do all the throttle action (and nextgen) 

Alas after much hair pulling it wasn't to be however.....

I did finally come across my missing box of Arduino stuff.

Finally my ethernet shield has surfaced!

This will do two things, firstly I can say goodbye to the laptop altogether now and control the base station directly from a phone or tablet. Way more convenient.

Secondly I can ditch the buggy USB connection in rocrail and connect via this port which uses its own set of libraries so I'm confident it should work more reliably and that will be the new path to sound.

I suspect the buggy behaviour might come from it being a clone Arduino with the cheaper usb chipset so it will be good to see how it behaves over Ethernet.

Also

Point motors!

 

 

 

 

 

[Sean]

A pretty simple upgrade.

 

Get base station

Remove motor shield

 

Plug all the shields back in. ethernet goes first as it has additional communication pins 

Motor shield on top to retain access to power terminals.

Now we have a standalone base station. No pc required.

 

Edited April 24, 2022 by Sean

[murphaph]

Are you running RocRail on a Raspberry Sean? I thought you were running the RocRail server on your PC.

[Sean]

nah its some old atom netbook from that weird point when they tried to make laptops as tiny and unergonomical as possible  so it has little other tangible use lol

[Sean]

Finally a breakthrough as i have hit a configuration that works!

the ethernet port is a godsend, if i just want to basically play trains i can now just start one of the apps on my phone and connect so its up and running instantaneously without the rigmarole of starting jmri/roc or even turning on a pc.

im still getting the same error message that was crashing out the usb link however it is totally ignored by a tcp connection so im assuming its coming in over the z21 network and rocrail doesnt know how to parse whatever it is, as usual the error messages were very cryptic.

not to worry as i was able to spend about an hour driving around the A class with an 071 sound file, no crashes, no command station dropout.

JMRI is not needed now so it will not really be used except for decoder programming as the decoder xml files are supposed to be compatible with roc.

next step will be running 2 nextgen processes from a single computer, that should be trivial enough. once it works plenty of solutions are available for routing audio to different outputs on windows.

as I see there are a few options from here. I can spend the bones of 700 euro getting ESU chips for my growing fleet (lul).... I can keep going with the bluetooth which is working however i need to source some super capacitors before its gonna work properly and the design needs slimming down for sure to get into baby GM's Ill keep going with that for now but progress is slow.

there is also another option i want to explore which would be putting a pair of speakers on the layout and somehow tracking the locos as they drive across it. if that was possible its should be easy to use that data within audio software to create a dynamic sound scape within the base board. one could also add an atmos track and sounds for other static things on the layout that would usually never get sound.

it could surely be done with block detection however there would need to be a lot of blocks to ensure accurate tracking. thats one for another night though LOL

I could also stick a fat subwoofer to the base of the layout so it vibrates as trains pass on it.......

edit: jaysus the tracking technology exists.

just imagine if he was waving around model trains instead of bottles lol, IF this works its going to become hilariously technical. above video tells me its going to work, I need to go to bed or im going to be juggling bottles before long!

Edited April 25, 2022 by Sean

[Sean]

New Arduino project; auto reverser for wye. Similar to digitrax ar1

[murphaph]

I had thought about that external speaker solution too but I don't know, I can't imagine it working as well as on board sound to be honest. The way I imagined it working was a fade in/out at "strategic locations of interest" so you'd mount a speaker at every station, yard, level crossing, signal etc. and just fade the appropriate audio in as the train approaches the speaker position, then fade the sound out as it moves away. No cacophony of sound from all these speakers. The trains run silent through "open country". 

For the baby GMs you could just buy Loksounds rather than trying tos squeeze the Bluetooth boards inside. A hybrid solution. Cheapo boards where they fit, Loksounds where major surgery is required.