Bryn_Bach_Railway

Aux 11 for esu, is F8 for Zimo and most others (esu skip AUX 8/9 for some reason) F8 isn’t supposed to do anything so will have a look at that.

When I tested the 8function with a volt meter, it only seems to give out around 4 volts. With a difference of around 1 volt when activated. That might be what the issue is as the logic circuits are most likely expecting closer to a difference of 3 Volts to activate each function. this seems to be backed up when testing the Zimo chip too, as the only logic level function with with a difference around 3 volts or more is the only one that works

Just checked the voltage across Dapol chips and a similar realist. The logic level functions that work drop to below 2V (actually down to near enough 0V, however the non-working functions stay above 2V. Would be interesting to see if someone with a non-sound ESU chip can check and see if all the function outputs drop to below 2V when activated.

There’s definitely some weird qwerks as to how DCC is done with this model (not really cavalex’s fault, from what I understand ESU have done the circuit board design). getting different results from different decoders with the same dip-switch settings. Zimo mn340C; F0f/r - head light (directional) F1 - markers front F2 - markers rear F3-9 - not working F10 - rear cab light (after cv change) Dapol 6 function F0f/r - head light (directional) F1 - markers front F2 - markers rear F3 - fan F4 - fan F5/6 - not working Dapol 8 function F0f/r - head light (directional) F1 - markers front F2 - markers rear F3-8 - not working would like to note that all decoders can operate all functions in a Dapol 68 too, so the decoder function outputs are working. I wonder if some of the logic level outputs are very voltage sensitive, as when a wire bridges the 5V pin and a specified output pin the appropriate function springs into life. However when going thought the decoder the functions do not work. interestingly when checking if the decoders outputs are working with a volt meter again the appropriate function pin and the 5v pin (when using a Zimo chip). When the functions are off, a reading of 4.81V is recorded. When the function is on, this drops to 2.13V for F3-9. However F10, which is the only logic level output that seems to work, drops to 1.65V. I don’t think that is really adjustable via CV’s to increase the drop, Only to reduce it I believe.

Just taken an 8function Dapol chip out of another model, and interestingly this one one do the fans at all, just F0-2

That’s interesting to hear as I quickly tested a 6function Dapol chip and had F3/F4 working (F5/6 wouldn’t have worked reguardless due to how I’ve set up that decoder) what positions are the dip switches set to?

Would be interested to see what results you get. I myself am trying to use a Zimo MN340C, and currently have the headlight working directionally, plus markers (F0f, F0f, F1 & F2) all working without modification. A couple of CV tweaks and I’ve got the read cab working too (F10), however the same teaks that are supposed to set up the front cab are not working. I’ve yet to get fans or tail lights (F3, F4, F5 & F6). Interestingly I’ve tested with a voltmeter and the decoder is giving an output, but the loco is not responding to it. Have tried swapping to full power too but not having much luck there either. Not entirely sure the decoder is swapping over tho.

It was the 6fct I believe. But I’ve mapped F5 to output 2 as my controller can’t hold f2 on. And I think I turned off f6 at the same time as I was going to set up tail lights at both ends but never got around to it. But f0f/r, and f1-4 all worked as expected. So all head/marker lights and fans

I have, like I said the Dapol chip works the fans (won’t work the tail lights due to how it’s programmed for my 68, yet to be upgraded to Zimo). hopefully it something I can change in the CV settings. Will have to check that later however. Does the voltage have to be exact 5v for the fans to work? also having an issue where I can get the rear cab light to work but not the front one. However I think that’s me needing to play with the settings more as it requires changing input pins to outputs.

If all else fails I’ll have to, however I don’t really want to be forced to use esu. Zimo gives me better control as I know exactly how the decoders perform, and know what cv’s I need to change to get the functions mapped how I want even on a gaugemaster prodigy. looking at the esu manual there’s not as much information available unless you have a lok-programmer etc. the decoder is giving an output on the correct pin, the loco for some reason is not accepting it. I’ll keep having a play to try and work out what’s up but it’s definitely a weird predicament.

Finally got mine today as a birthday gift, however having quite a weird issue with DCC. Using a Dapol chip, I can get the fans working fine, and the decoder supply’s 5 volts. (Tail lights don’t work due to the way I’ve re-programmed the decoder used for testing), however, using a Zimo mn340C, the decoder only seems to be supplying 3ish volts and the fans do not work. But when the Zimo chip is in another loco, it can supply the full 5 volts just fine? Not an issue I’ve encountered before.

With double heading or pushing stock, it entirely depends on how the kinematic coupling is designed. If it’s completely free from the bogie and is very free moving, then when pushing or double heading (if the following loco is faster) the coupling gets push to the outside of the curve rather than pulled inward. However if the coupling is guided by the bogies like the accurascale 37 or a lot of coaching stock (still kinematic and not attached to the bogie, but if the bogie turns a lot, the coupler is nudged over too) then the couplers stay on the inside of the curve when being pushed and double headed as well as being pulled. That’s in my experience anyways.

Would be nice, although I do seem to remember accurascale stating they were not going to do it as they had too much on their plate. Whether that’s changed tho I don’t know. Could be another manufacturer tho. I also remember the expression of interest was going to try find a new manufacturer.

Preferably with a New Caledonian sleeper 92 to match ;) depending on the budget at the time. I’d certainly love to get a full sleeper set. Despite it technically being out of region. Just hope the factory get the back to backs on the wheels a bit more accurate next time now they’ve had some practice!

Is there a function list available for these yet? Mainly the lighting functions? Would also be handy to know if these are using ESU’s proprietary set up to access all the functions, done using the susi output pins, or if they’ll all be accessible via the 10(+2 directional) outputs on the 21pin interface. I know this was discussed a lot in the 37 thread so I’d like to make clear that for these models, being a staple of the modern railways it won’t affect my order of all 10 versions. I’m more asking to know if I can go ahead with purchasing my preferred Zimo decoders of choice and just do some programming, or if I need to wait for the non-sound ESU ones for full functionality.

Update with the partial.ly payment situation. contacted support this morning (via email this time), and as partial.ly are still having issues a work-around was used. So my original order was cancelled l, with a new duplicate order created and marked as paid so dispatch won’t be affected. Great help as always from Patrick. Hopefully we might see these start to ship this week if the timescale hasn’t changed from previous posts in this thread.

I believe it was stated in the Hornby Magazine video that it is a NEM socket. But the auto-uncoupler is part of the tension lock coupling and has a easy to disconnect electrical connection (i would guess something think most Hornby steam locos)

Will do on Monday. Looking at the online chat all the support guys are away till then which is completely understandable. Hopefully there’s an easy solution.

Is there any update on the partial.ly payments not showing correctly on the accurascale website? I’ve got a rake of 5 of these on order paid through partial.ly and despite me fully paying back in December, the accurascale website still shows “partially paid” with a remaining balance. i did contact support about a month ago about it and was told a fix should be made in the next few weeks, however it’s still showing incorrectly. So just wanted to check here if it’s still a known issue or just a me issue at this point. Just getting slightly paranoid this will affect my order and end up in me missing out. 😅

From my understanding, the body shape is the same. But the lights, roof’s and exhausts as well as some other details will be different. Working fans will only be on the SFX (sound fitted deluxe) models

You should be ok with any 10 function chip. Some re-mapping or re-programming might be needed tho depending if functions use logic level or are of different aux ports etc. but going off the list provided here they should all be accessible off the 21 pin interface. If in any doubt cavalex are working on a pre-programmed esu chip tho. my pair will be fitted with Zimo MN340’s, however I’ll have to report back on the results as i wont be able to get at mine until the 17th.

Different combinations of lights can be set up with function mapping for exact variations (even using Swiss mapping for more complex setups). We should be able to operate markers, day headlights, taillights, night headlights, and high intensity lights (obviously not all models have all those lights etc) on any decoder with enough functions (eg a 10 function decoder). So in effect the lights on the outside of the model, and that you’d actually see in use if you stood at a station or line-side watching trains go by a various times of day. Internal lights like dials or engine room lighting are nice to have, but far from essential. Same could even be said for cab lights as these are only really used for start up or depot moves and not commonly on for mainline running.

The aux pins are the standard for function outputs. 10 outputs (excluding front and rear lighting) for anything the model wants to incorporate. But as any 10 function decoder would use all these pins (granted they may be in a different order) then all the lighting outputs on these pins should work. However the extra functions (accessed using Esau’s custom setup) won’t. It’s a case of what functions were mapped to outputs only esu can access. And that the esu custom set up seems to be affecting the normal access to the 10 aux pins. like I said in my past post. I’ve made my points. I’m not going to keep repeating myself. But we should not have to use esu just to get proper lighting

Going to make my last comment on the DCC issue, as quite frankly I’ve made my points clear and I’m just repeating myself. the main cause of the issue is the more ‘novelty’ features included. Yes I agree these are nice to have but these are the ones that should be on functions that only ESU can access. Or operated by a different system (physical switches on/in the model or a magnetic wand or some other way). Without those 3 features taking up DCC decoder functions, there are 10 lighting outputs plus front and rear lights in use. which happens to be the exact amount a 10 function DCC decoder is expected to work with. and so there would not be any issue here as it’s already been established that some reprogramming to match up these functions is expected. at the end of the day, if you advertise your model as being DCC ready with a specific standard socket. It will be expected for the model to work with all key functions with any decoder that is also matched to that standard socket with enough functions.

If models were made to follow the standard properly. Then accurascale going out of buisness would not have an affect, would be undoubtedly a very sad time however. Some goes for other chips. If the standard is followed then any chip with enough functions should work. It’s only a concern now that these models are not working with the standard. I should’ve been more clear here I admit. I was referring to the lighting functions. Any needed for standard prototypical running should be classed as basic functions.