SlotForum banner
1 - 20 of 25 Posts

·
DT
Joined
·
5,195 Posts
Discussion Starter · #1 ·
OK, here it is, the reply from Lars, the DCC engineer. Remember that he is from a train background, but he is intrigued byt the application of DCC to slotcars. This is what he said:QUOTE I have read thru your pages on the forum. It is interesting to see all the
similarities between you slotcar guys and us railway guys. We had the same
discussion about the necessity of these new digital gizmos. Can I still run
the old vehickles on a digital setup? What about a club that runs digital,
can one switch back in a simple way? I dont care about all this new
functions and will NEVER use this at home, allI I want to do is run fast,
there is no time for changing lane and so on.

Well, in a year or two most commercial cars will be digital, either people
like it or not. There will be functions that you never thought would pe
possible. Pit stops for fueling, disabled cars after craches, light and
sound, lap counters and timer functions. You name it and it will be
possible. It will be possible to simulate a wet track. Sound, light and
punctures. The slot car hobby will change face and will never be the same.
The young guys will like it, and the yet younger will grow up with it and
some older will never accept it. We have the same in railroading.

I don´t think I will jump in on your conversations. I don´t need a new
hobby right now :) but my system is there on the Internet free for you to
play with. The system is fully NMRA-DCC compatible, that is the same as
your Arnolsd system and the Digitrax system that someone did play with. So
my system can run your cars and the Digitrax cars and all other railroad
DCC-decoders.

I did see that someone pointed out that a DCC-system by default was unable
to have an instant response from a controller. That is not true. Perhaps
some commercial systems function that way, but the DCC standard does not by
default prevents this. My system can instantly bring a locomotive from full
speed forward to stop, and even to full speed reverse. Even if this is not
desirable when runing trains, it is possible. If you go from fast forward
to stop the vehickle will coast to stop. It will not do any active braking.
Applying a reverse power will cause active braking, and so will a mechanism
that shorts out the motor. That is something for you guys to solve.

As I said earlier, my controller consists of one variable resistor and
thera are no high current passing the controller, hence it will never be
hot and burn out. Also you need a pushbutton to control the functions. So I
guess the system will be able to do what you deire. And it can run the cars
you already have chiped, with the light functions and all.

As you already have showed that you can use regular railroading decoders I
no longer need to know the amperage of yur cars.

And a last thaught. Will Scalextric use the stndard train DCC protocol in
their system.? I mean, will DCC be the standard car digital system?

Here is the url to my site:
http://www.geocities.com/tillorp/

and here is the system:
http://www.geocities.com/tillorp/tmwdcc.html

Feel free to contact me in this matter, or in any matter of course :)

Regards
Lars
 

·
Julius Wilkko
Joined
·
935 Posts
Hi!

That's interesting! But I have already come across this guy while browsing the web for DCC info. He is from Sweden, I am from Finland. Why is it now that us scandinavians are so eager to develope something new and willing to share all the information? But lets discuss specs. So far we know what people want for digital system, here's a list:

1. Compatible with any car or any track
2. Affordable
3. Easy to use
4. No digital lag (as small as possible)
5. Lap counting and lane-change solved
6. Small car-decoders
7. Reliable in race
8. Heavy duty version for commercial use
9. Active braking + brake light option
10. Weather, fuel, pit-stop implemented
11. Anti-collision system
12. Working headlights with flash-option

Discussion at this thread should be consentrated for solving how this system could be implemented using RR-DCC for basis for this new CarDCC. In my opinion biggest technical problems will come with #5 and #7.

Any takers?

Julius
 

·
DT
Joined
·
5,195 Posts
Discussion Starter · #3 ·
I was asking Lars about the controller and how we could make some for slot cars. This is what he said in reply:QUOTE I don´t think it would be very difficult to modify a trigger type
controller and use it with TMWDCC. Eiter you can try to find a resistor
that can replace the 25ohm resistor you normaly use or you replace it with
a potentiometer. The value depends on the speed of the computer you use.
http://www.geocities.com/tillorp/potvalue.html

You could wind a string around the shaft of the pot and let the trigger
pull the string, and have a spring to pull it back. No problem. And you
need a pushbuttom to control the functions. What I have in mind is the
type-C controller (Throttle in railway language)
http://www.geocities.com/tillorp/typec.html

The TMWDCC-modules you need to build to run the cars and to program
decoders are a TMW01 (processor card) and a Booster (TMW05, or if you need
more power a NMRAF7 or 8) That is all. You do not need the other
TMW-modules. They are extras used for reading out valuse from decoders and
for building a special programming track for trains.

The system will run on any old PC from 8086 and up to a fast pentium
machine. You do not even need a hard disk, it runs from a bootable floppy.

So have a look at
http://www.geocities.com/tillorp/hw.html
to find out about the TMW-modules and controllers (throttles).
 

·
Beppe Giannini
Joined
·
1,696 Posts
QUOTE Why is it now that us scandinavians are so eager to develope something new and willing to share all the information?
I really hope your nordic thesis is right, Julius !

Just quibbling, in my book these are functional specs - hats off to Alan/Beejay who pointed out that establishing these first is the obvious way to proceed - but we should try to quantify as much as possible (e.g. how many ms is an acceptable digital lag ?)

One immediate application of the specs is providing a matrix against which one can evaluate the present and upcoming commercial systems

I'm totally out of my depth when it comes to DCC "internals", so I'll leave it to you to discuss whether NMRA-compliant protocol is suitable - correct me if I'm wrong, but I thought all existing systems (save the first generation ACC Davic) are DCC, it's just that they are not NMRA compliant - David Laurent told me Davic isn't

OK, my contribution to the list :

A ) Number of cars. Will somebody please dispute my contention that 6 cars running fills 99% of the requirement, with about 15 as the absolute maximum ?
I believe this has an impact on the system

B ) Decoder ampacity. This should be "as high as possible". How high ? Ideally, IMO up to 2 ohm arms. But does that set the current limit or can one rely on software overcurrent protection in the decoder ? BTW I wonder if the slight delay experienced by Prez for SCX in acceleration only (not modulation) isn't due to some sort of protection

C ) Number of speed steps. Once you can set Vo as a CV (which is equivalent to selecting your resistor controller ohms) how many steps are really needed ? I had mentioned as a possible reference the number of diodes in a PM controller - another could be the coils in say a 35 ohm resistor

D ) Intrinsically safe (from cheating) design. I mentioned this in another post, as a caution against adding too many bells and whistles (but Astro contradicted me). The mere suspicion that the decoder could be tampered with - traction control being the first thing that comes to mind - would sour any race. Similarly, if you introduce outside limitations (like fuel load/tire wear simulation) couldn't a decoder override them ?

Ciao
Beppe
 

·
Vendor
Joined
·
2,940 Posts
QUOTE Why is it now that us scandinavians are so eager to develope something new and willing to share all the information?

mmmh... we should ask Mr. Linus Torvalds


Maurizio
 

·
Registered
Joined
·
715 Posts
Would it make any sense to propose a list/order of functions/byte values such as:

0 - Eng Speed (Momentary)
1 - Lights (Latched)
2 - Brakes/Brake Lights (Momentary)
3 - Steering (Momentary)
4 - Horn/Spcl 4 (Momentary)
5 - Spcl 5 (latched)

================
That way down the line some geniuses can add working convertible tops, waving driver arms, adjustable Can Am wings.

Not like I know what I am talking about, but I'm just trying to think ahead. Maybe nothing like this is needed.

-Maltese
 

·
Julius Wilkko
Joined
·
935 Posts
What! No takers?

(other than Nuro, Maltese and Xlot)


Doesn't matter. I will proceed with designing CarDCC anyway. I hope that SlotForum moderators will let me use this thread as my weblog where I will walk you through the design process of CarDCC. It will take some time to get to the finished product, if ever.
Usually I am able to get results relatively quickly if I put my mind to it. Feel free to add comments or suggestions to this thread but please stay within subject.

Julius
 

·
Beppe Giannini
Joined
·
1,696 Posts
Great, Julius - I'm looking forward to reading your blog (and possibly understanding some of it...)

Now

QUOTE but please stay within subject

I do hope what follows will be considered as such, if it isn't please forgive me and do not take umbrage

It seems to me that there are two possible outcomes :

- the "Linux/NMRA" scenario where we, the people, decide what we want and manage to have it adopted by the industry. Needless to say, in an ideal world this would be the ideal option

- the "Windows" scenario where one manufacturer produces a system that's generally acceptable, and thus headed for wide scale adoption (not making names, it would be either Scalextric or Ninco). Then, "we" could supplement it with aftermarket components and software, and make it fully suitable for our requirements

[please consider that I have no personal preference - you are very much aware of the pros and cons, I would just point out that - unless you go for routed tracks - one would still depend on manufacturers for the special track pieces]

OK, cutting to the chase, my suggestion is that - in parallel with working on pure CarDCC - "we" could dissect commercial systems, analyze their protocol and evaluate performance and shortcomings. One would obviously start with SSD (no point in wasting time and energy on SCX)

I don't know if it makes sense, but one advantage might be that Car DCC protocol could be made compatible for the mandatory functions (say ID assignment and speed) and then expand to other functions

Would this be feasible and represent a lot of work ? If it were, I would be willing to contribute (if only financially) to the effort

Ciao
Beppe
 

·
DT
Joined
·
5,195 Posts
Discussion Starter · #9 ·
Please go ahead. I'll introduce you to some interesting people in this field in the near future.
 

·
Beppe Giannini
Joined
·
1,696 Posts
Ha !!! Et tu, Nure ? First, you squelch that nail biting "stirring or news" thread, and then leave us with bated breath on this one
 

·
DT
Joined
·
5,195 Posts
OK, I'll tell you.

I've been speaking to the gentlemen who designed and implimented the NMRA DCC standards for trains. These people are very interested in using DCC for cars and have been looking through our forum at contributions. They agree that we must look hard at the Scalextric products. I'll let you know more when I'm next in touch with them.
 

·
Julius Wilkko
Joined
·
935 Posts
Hi!

Thanks for your comments Xlot, Nuro. Looking forward to possibly hearing from RR-DCC people. I could dissect commercial systems and evaluate how those work, but SCX system is quite pricey so I'm not willing to purchase it just to see how it works. I am considering buying and reverse-engineering Scalex system when it will be available.

BLOG continues....

Assessment of competition

Before any start of design it's very useful to have a look at competition. These being SCX, Scalextric, Davic and Carrera digital systems. You don't want to re-invent the wheel so you pick up good ideas and learn from mistakes of competitors. Here's what we know so far:

SCX:
+ Uses track for communication (DCC type?)
+ Programmable car ID's
+ Lap-counting solved
+ Mechanical LC implementation allows as many LC pieces as desired at track
+ Headlights
- Requires special digital hand controllers
- Expensive cars
- Very very poor compatibility with other makes due to special guide and track
- Some digital lag ???
- It has been said that SCX digital cars must have magnets, otherwice LC not accurate
- Digital chip not for sale separately, hopefully will be in future
- Limited to 6 cars
- No brakelights
- Special digital power supply
- No PC-software, or interface to PC ???
? No information whether lap-timing is solved

Scalextric
+ Uses track for communication (DCC type?)
+ Programmable car ID's ???
+ Lap-counting solved
+ Directly compatible with existing ScalextricSport, ScalextricClassic and NINCO tracks
+ Car chips will be available as separate components
- Not 100% compatible becouse you have to drill a hole to car chassis for LC/Counting LED
- Feedback from the car to the track is optical, strong ambient lighting may cause disturbance
- Requires special digital hand controllers
- Limited to 6 cars
- Special digital power supply
? Digital lag
? No information whether lap-timing is solved
? PC-software available
? Price
? Headlights
? Brakelights

Carrera
+ Uses track for communication (DCC type?)
+ Programmable car ID's
+ Lap-counting solved
+ Compatible with excisting Carrera track
- Car ID selection implemented with DIP switches?
- Requires special digital hand controllers
- Very poor compatibility due to special guide
- Limited to 4 cars
? No information whether lap-timing is solved
? Price
? Headlights
? Brakelights
? PC software
? Digital lag

Davic
+ Uses track for communication (DCC type?)
+ Programmable car ID's
+ 100% compatible with any car ever manufactured, available current for car motor limited
+ You can use any variable resistor type hand controller, 100% compatibility here also
+ Number of cars 16 ???
+ LC piece manufactured for NINCO, so direct compatibility with NINCO, Sport and Classic tracks
+ Lap timing and counting apparently solved and functional
+ PC-software/connection available ???
- Not available for regular home racer
- Very very expensive
- No headlights ???
- No brakelights ???
? Does not comply CE regulations, may disturb radio and TV seriously
? Digital lag

I emphasize that these are my personal findings, feel free to correct and disagree. Seems to me that the Davic system is the best of the four. I think that this is quite obvious becouse Davic was developed by slotcar enthusiasts. 100% compatibility is most important. Very unfortunate that Davic system is not available for regular home racers and it is very expensive. Scalextric system is most promising for home racers becouse it will provide the best compatibility of the three mass-produced systems. Two things are very disappointing though. 1# It introduces special digital hand controllers, you cannot use your favourite variable resistance controller. 2# Feedback from car to track is optical, requires drilling a hole to your car chassis. So far there is a consensus that SCX and Carrera systems have serious shortcomings.

I will now proceed with the design compiling specification and determining what kind of technology will be used for CarDCC.

Julius
 

·
Beppe Giannini
Joined
·
1,696 Posts
Julius (please bear with me)

SCX
no dynamic braking
no timing

Scalextric
2 modes of braking (although I don't know if button braking is just a trigger by-pass)
presumably the car must not be sliding when it goes over the sensor

Davic
yes braking

Nuro,
I've been thinking (
) : as I believe Julius said a while ago, it would be great to have David Laurent on board
I could give you his email address, but it would be much better if you could get to meet him say at Eupen (where you are going - to atone for your avowed addiction to magnets - aren't you ?)
 

·
Registered
Joined
·
3,883 Posts
QUOTE I hope that SlotForum moderators will let me use this thread as my weblog
In a lengthy absence, I missed the beginning of this topic.
Now quickly and belatedly adding, not only LET this thread be used as a technical weblog, but actively encourage it and reasonably, though very firmly, request that non-technical members absolutely not dilute it in any way (including myself!)

Any urge for non-technical others to discuss points outside that guideline can easily be accommodated in another, separate topic.
 

·
Julius Wilkko
Joined
·
935 Posts
Hi again!

Xlot, thank you for your comments. Would be great to have David Laurent at the Forum. It's nice to have "official" acceptance to use this thread as blog, thanks Tropi.

BLOG continues....

This is what I will be aiming at, CarDcc Preliminary Specification:

+ Uses track for communication (DCC type)
+ Programmable car ID's
+ Lap-counting and timing solved
+ Compatible with any car, no special mods for chassis
+ Compatible with any variable resistance controller
+ Affordable electronics
+ Minimized digital lag
+ Headlights, tail-lights and brakelights built into car decoder
+ Number of cars 8
+ Normal braking at decoder, no negative voltage dynamic braking
- Motor may have to be limited to NC1 type
- Will not comply with any CE regulations, may disturb radio/TV
- Not possible to mass-produce LC pieces. Will rely on Scalex
- LC pieces will be connected directly to command station

Technology:
* Regular hand controllers connected to command station
* You will be able to personalize your controller with two adjustments
* Separate ADCs to minimize digital lag, PIC micro controls operation
* Commands from control station to car electrically DCC type
* Command protocol has to be optimized for speed and reliability
* One option is to provide clock for each data bit
* Car decoder is 3rd gen DCC type tranceiver, added lighting features, as small as possible
* Car decoder simply installed between guide and motor, motor drive is PWM
* Braking at decoder, implementation with FET
* Car uses HALL sensor for position tracking, sensor placed behind right front tyre
* Command station asks the car where it is, the car answers either yes or no - one bit answer
* Car answer is electrically 3rd gen DCC type
* Magnets installed under track will tell the car its position at the track
* Laptiming is done with any excisting lapcounter/timer sensors
* Each LC piece is is connected directly to command station
* I will try to get it working and as affordable and simple as possible

Feel free to comment on spec/technical aspect. Lets see how it goes. I do not know yet if I am able to pull this through. Anyway I will spend less time watching TV and more time designing and that's always good.

Julius
 

·
Julius Wilkko
Joined
·
935 Posts
BLOG Continues...

This time I will present preliminary scetch for communication protocol.

Function:
Command station sends dynamic 5-14 bitlength messages for a car. Car answers one-bit answers "YES" or "NO" for the command station if necessary. This needs more explaining. The car has to be able to indicate its position at the rack. Car senses its position with HALL sensor. HALL sensor detects magnets installed under the track. If I assign 3bits for car position information it is possible to have starting line detection and 7 lane change requests. Command station will ask the car series of questions: Have you passed the starting line? Are you approaching lane change 1? Are you approaching lane change 2? Car answer is always either yes or no. It will be very hard to get the data from car to command station and this is the reason for minimal communication from car to command station. Command station will start asking car its LC position info only if a driver pushes LC button or if LC is set to automatic mode.

Preliminary scetch for command messages:



Feel free to comment


Julius

The following part will describe timings and electrical structure of messages.....
 

·
Julius Wilkko
Joined
·
935 Posts
BLOG continues...

I will try to ensure error free communication by providing start bit for each data bit. This type of communication has been widely used with TV/video data transfer. Basically signal contains its own clock.



Next, timings

Julius
 

·
Registered
Joined
·
65 Posts
Hi,

Few comments:

What i have noticed is that every message needs "start character" instead of start bit. F.E. in NMEA sentences there is "$" character in front of each message. (NMEA is communication protocol between gps receivers and other stuff like map parser software etc..). The reason is that it is assycronous serial protocol and microcontroller needs some "safe" start point when it reads its RX buffer. Easiest and safest way is to write a parser program into microcontroller which searchs "$" character. When "$" is found then we know that next byte is information A and so on.. Conserning data link (RF or wired), use of start character makes system more robust.

Reading the buffer:

During action there will be situation where microcontoller starts to read buffer in the middle of the message. Filling the registers starts when "$" comes out. There must be robust parser program which counts bits and fills every information into right place. Offcourse we do not read the buffer if the address program doesn't give "true" value. Address program is a short loop which is also reading buffer and searching its own address. So before address there must also be start character (which is same for all cars). When "address" start character has been found and the next byte is correct address then lets return "true" value and start message read program (which is the parser loop).

Hamming coding:

When message has been read there must be way to check if the message is valid. If it is not valid then lets do nothing and read next message from buffer (means that we must start "address loop " again. Simple hamming coding is easiest and safe enough to use.

These are minimum requirements if trying to have robust datalink for DCC. I have tried differend kind of datalinks (other than slotcar applications) without securing these points and the result has allways been a disaster
Protocol will be fast enough.

To make parser program simple and fast the messages must have constant lenght. So shortening message randomly is not wise (full throttle). Besides in our home tracks (anound 20m with max 6m straights) fullthrottle situation is very unusual. Actually i would want to have analog systems "control dynamic" to saved as same as is is now. I don't believe that one is able to drive constant fullthrottle longer than 1 sec in most home layouts.

One practical example that why protocol needs to have relatively high secure percent:

When controlling some thing with one bit (0 or 1), there is high propability for error triggering (message validation process must be good). If controlling same thing with byte there is lower propability for error triggering. (message validation needed only for getting valid data often enough). I had long and educative way when i was developing one radio transmitter which was abdle to be configured remotely. I started to control it with one bit (0 was for shutdown and 1 was for transmit). Becouse of previously explained reasons the reliability of the system was poor. I had to make it in the way what i learned and told here. No matter is the data transmitted via rails or RF link. Same problems.

IMO high reliability is needed in proper DCC. Otherwise drivers will get angry


Just few thoughts

Best Regards:

Sami
 

·
Julius Wilkko
Joined
·
935 Posts
Thanks for your comments, Sami

Fear not, everything has been taken care of. This next part describes exactly what you are complaining about: synchronization and robustness of data transfer. I think you will find answers at the following text.

BLOG continues...

I am planning on using 10KHz maximum frequency for sending data packets from command station to car. Each bit in a message will take 2 clock cycles to send. One 10KHz clock cycle takes time: 1/10000=0.0001=100us. Maximum message contains 14bits so it takes 14bits x 100us x 2cycles =2800us to send it. There has to be some spare time between messages. During this time car can answer command station and reset and synchronize its communication. I'd guess that 1000us should be adequate. Total time that is needed to update data for 8 cars with maximum message is: (2800us + 1000us) x 8cars = 30400us. This means that with worst case scenario data of a single car is updated about 1000000us/30400us = 32 times/sec. With minimum 5bit messages update rate is naturally higher. If everyone is driving at full speed and doesn't bother to change lanes, the data for a single car is updated 1000000us/(((5bits x 100us x 2cycles) + 1000us) x 8cars) = 62,5times/sec.

I will select 4MHz PIC device for a car decoder. This device is able to excecute a command in 1us. I am reminding that messages have built-in synchronizing clock - basically decoder calibrates communication for each and every bit. Start bit of every message bit will stay LOW 50us and high 50us. Data bit itself is 100us - so I will have plenty of time to do all kinds of checking at car decoder. During 1000us pause between two messages the command line will stay HIGH. The decoder chip will reset and re-synchronize communication during this time. Good margins are essential for good design. Decoder software should be very very robust.

Command station will contain 20MHz PIC device. One command takes 200ns to excecute. There will be 1000us time between messages. During this time command station PIC has to read car answer and controllers. It will have to read LC buttons and activate LC. It will have 5000 instructions (1000us/0.2us) available to do all this.

I emphasize that all this is preliminary work to figure out what are possible timings and characteristics. When I get to electrical testing I will see if this communication is reliable enough and if it is possible to beef up the system with faster communication.



Julius
 
1 - 20 of 25 Posts
Top