Bryn_Bach_Railway

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.

The extra features are not the problem, it’s where they’ve been placed and where other more required features are. And the fact that the enabling of extra features seems to be disabling basic features for non-esu. if a model is made with a standard interface, then that standard should come first. We all want extra features but not at the expense of non-standard wiring. Making everyone use ESU might be fine for most now. But what happens if ESU go out of business? Or stop making 21 pin decoders for whatever reason. Then everyone who didn’t already have these models DCC fitted is in the same boat. as for Apple, when you buy them you know certain features are non-standard. But they are also not listed to be following a standard either.

Anything needed for protypical operation would seem basic to me

Any high end 10 function chip should be able to operate the functions for head and tail lights, plus the first 10 function outputs. That is the standard. Any innovation beyond this standard should not affect this. And if that’s not possible then maybe it’s time manufacturers start looking to make a new standard with more features available. Or use other methods to operate non-essential features.

The difference there is most detailed programming details for those examples are not based off a standard. And so makes sense that you wouldn’t be able to access it easily. However the 21 pin interface is a standard. And Accurascale and ESU, have expanded on the standard (great for ESU users) but it seems to have been done in a way that makes it non-standard for core features. If it was the engine room lights and dial lights not accessible, then that’s fair enough. But that fact that it’s featured needed for normal running is not ok. And the fact that the extra functionality seems to be affecting the normal standard.

The problem isn’t that the decoder of choice isn’t working out of the box and straight in the loco, and it’s already been stated that with loads of functions on modern models any decoder will likely need programming and re-mapping. The problem is that even after the decoder is being reprogrammed to use the function ports that the lights are apparently on, it’s still not working. And even if it was, some functions that are required for normal running are placed outside of the normal 10 functions another DCC decoder could access, but novelty features are accessible which is backwards.

if a model is made following the DCC standard, any 21 pin chip with enough functions should work. The problem here seems to be with the extra functions that only esu can use, and the face that some of these are what would be classed as core functions to most (some directional lighting aspects) but also the fact that it seems to be braking other functions for non esu decoders too. At the end of the day if adding extra features such as dial lights or engine room lights is going to lead to a situation where only ESU chips can operate all standard functions, then it’s time to question if those features are needed. Or if they can be controlled by a different method (magnetic wand etc). There’s no problem with accurascale working with ESU for the model. Cavalex have for their 56. But all features are on function ports accessible to any 10 function decoder.

This I don’t agree with. If a new thread is started, then there’s no garentee that the accurascale guys will see it, or if they do, there’s no garentee it will be remembered if they decide to reference it for future update etc. (not that this thread garentee’s that either, but it increases the odds by a fair bit) private messaging means all the information is not easily available for others who might have the same issue. bloodnok has already stated that they have not had much luck with the support services, and so this thread is the next port of call. After all this is a general thread for all comments and queries about the model, if there’s some comments that don’t interest you then just skip over them. But having the discussion here keeps everything to do with the model in one place, and provides the most support from the manufacturers active members.

Sorry to keep asking about this but am I right In thinking these are going off what ESU call the aux ports? as such, going off the diagram helpfully provided by @Bloodnok, aux7 would be FA9 on Zimo, with all the others lining up with ESU?

That’s a very useful diagram. I’ll be saving that for future reference. Thanks!

I should’ve made it clear I was referring to the modern ones with WIPAC’s. It’s been a long day at work and clearly I need some rest!

Granted the cavalex 56 doesn’t have as many functions in use as the AS 37. But they have been far more helpful here from what I can gather. There are standards for a reason tho and restricting full functionality essential to one brand is not the right approach. I’d take a guess that it’s because they don’t normaly go above F5/6. Which is where decoders seem to vary from the standard or allow different options for this pins depending on cv settings. As such it would leave them with more questions about why a certain function isn’t working when it might be down to the decoders settings and not the model

I understand what you’re saying, in effect esu have re-labeled aux 8 to be aux 11 on their chips then. But the point still stands that all head/tail light functionality should be on the 10 (12 including directional lighting) functions accessible from the 21 pin interface. And that’s completely agreeable, there’s a standard for a reason

That was me assuming a 10 function decoder was used and such the functions linked up with AUX ports, however you make a good point. I’ll update the list now to just list AUX ports

ESU might choose to skip Aux 8 and Aux 9. But the NMRA standard does not. Why esu do I don’t know, but it shouldn’t matter. Completely agree with the fact that dial and engine room lights are not essential, but anything on the outside for head or tail light arrangement is. And as for the ordering. All the lights work on dc models to me knowledge, so how swapping them around would change what ones are accessible doesn’t make much sense

Using the logic of F3/4 doing the fans, the aux list should then be; F0f - headlight front F0r - headlight rear aux1 - front markers aux2 - rear markers aux3 - fan #1 aux4 - fan #2 aux5 - front tails aux6 - rear tails aux7 - front cab aux10 - rear cab *that’s all based off information on this forum. I can’t test it myself just yet. But once I have my pair i will and update if it’s not been solved by then*

Zimo mn340’s should access upto aux 9 at least. Unsure if they can work aux 10 or if that’s solder to the decoder only. Might need to adjust some CV’s to unlock all functions but they should be able to work them

Looking at the DCC standard and then the list of functions and AUX ports for the AS37 there are a few confusing things especially when ‘core functionality’ should work with any high end chip. I think it’s fair to assume higher end chips should be able to work F0f and F0r, and then aux 1-10. Using this logic, putting the top headlights on aux ports outside of this range, but dashboard lighting and engine room lighting within seems very backwards. At the very least these should be the other way around.

Which still forces anyone wanting to use those extra functions to have to use ESU. Core functionally should be accessible to any DCC decoder for the socket. But all high end chips should do all functions. Granted some re-mapping might be needed, but making it not possible for all but one brand isn’t great.

There was a list posted a few days ago that had the aux function outputs and what they all did. I believe there was a list of 9? Using F0f and F0r and then aux 1/2/5/6/7/10. Personally I’d then cross check them with what the decoder manual says. Can’t look myself atm as I won’t be able to get at my pair of 56’s until mid feb