Recent

Author Topic: NMRA DCC train control project.  (Read 17376 times)

irfanbagus

  • Jr. Member
  • **
  • Posts: 60
Re: NMRA DCC train control project.
« Reply #15 on: April 27, 2014, 07:03:44 pm »
What does "grace of the scheduler" mean. I know I should know that, but my head keeps coming up empty. <wife nods knowingly>  ::)

The last couple of motherboards I bought had serial ports. No appearances on the back panel, but there were pins on the board that could be brought out. I was pleasantly surprised to find them still there.
your problem is not with serial port. it's about timing. in linux (or any others multi tasking os) your program running with others process. virtually, your program just running without care about others process. in reality it stopped every few us/ms by kernel to give opportunity for others process to run.

to achieve us precision you need non multi tasking os (like dos) or real-time os. linux support real-time but afaik none of desktop oriented (like ubuntu) support by default and writing rt program on linux is harder compared to regular program. use cheap ($1-$3) micro-controller is easier.

CaptBill

  • Sr. Member
  • ****
  • Posts: 435
Re: NMRA DCC train control project.
« Reply #16 on: April 27, 2014, 08:51:53 pm »
I'm not a Linux user, so be warned.

While everyone tried to convince you that it is not possible and not cost effective without a micro controller, which might be true, I have the opposite "feeling". You mentioned Ubuntu in your first post, maybe you should take a look at this. Might not be that easy though.

Oh, don't get me wrong. I actually have a sweet little TinyCore-RT kernel which was rather easy to compile as a matter of fact. If anyone is just determined to go without a separate microcontroller, let me know. I can set you up with a cool little RT kernel and walk you though installing FPC/Lazarus and set up TLazSerial in less than 45 minutes flat. That's the sad thing. Haha. I spent all that work and effort to find the ultimate RT setup for doing CNC/shop automation, then I ran saw this:

This is running on a $10 ARM based micro controller.
Now I am back at the drawing board. Haha

http://youtu.be/Om0wTqFA-Dw

Rails

  • Guest
Re: NMRA DCC train control project.
« Reply #17 on: April 27, 2014, 09:03:53 pm »
What does "grace of the scheduler" mean. I know I should know that, but my head keeps coming up empty. <wife nods knowingly>  ::)

The last couple of motherboards I bought had serial ports. No appearances on the back panel, but there were pins on the board that could be brought out. I was pleasantly surprised to find them still there.

your problem is not with serial port. it's about timing. in linux (or any others multi tasking os) your program running with others process. virtually, your program just running without care about others process. in reality it stopped every few us/ms by kernel to give opportunity for others process to run.

to achieve us precision you need non multi tasking os (like dos) or real-time os. linux support real-time but afaik none of desktop oriented (like ubuntu) support by default and writing rt program on linux is harder compared to regular program. use cheap ($1-$3) micro-controller is easier.

What in the world does your post have to do with what you quoted?  %)

MrJohn

  • New Member
  • *
  • Posts: 22
Re: NMRA DCC train control project.
« Reply #18 on: April 27, 2014, 09:19:29 pm »
Thanks for the comments..

Marcov, the protocol does allow some jitter in the length of data pulses and half the pulses are not time critical at all.  Data drop outs are expected and are allowed for by the data packets being continually resent, it just remains to be seen if whatever issues there are with timing in the operating system are enough to make the operation unsatisfactory.

Your comments regarding the serial ports and ease of distribution are noted but those issues are less of a concern to me than doing the project for my own satisfaction.

Rails, am yet to find just what the timing issues thrown up by the operating system will be but that is part of this project.

Engkin/Rails thanks for those links which are very encouraging.

 irfanbagus, yes, timing is the principal challenge in this project.

I dont want to make this a hardware development project.

CaptBill,  fortunately the model trains are not quite as demanding as CNC as some lost data is not a show stopper.

MrJohn

  • New Member
  • *
  • Posts: 22
Re: NMRA DCC train control project.
« Reply #19 on: May 02, 2014, 10:31:12 pm »
Just an update on this project...

I have abandoned (for now) the idea of using a serial port due to the latency issues but that does not mean I might not go back to it in the future!  Using the serial port has the advantage that no hardware DCC controller was required and would have connected directly to the commercial DCC "Power Stations".

I have also abandoned the use of Ubuntu having got a good flea in my ear from the supplier of the new computer that failed to restore itself after a Ubuntu installation went wrong side up,  but that is another thing I might come back to.

Meanwhile, I am dusting off the work/play I did some months ago to use the audio for output of the digital data stream.  This has the disadvantage that hardware is required to shape the wave form but it is a very simple op amp circuit.  It seems to work too..

https://farm4.staticflickr.com/3768/10033122854_ce1e171971.jpg
... the audio trace and the square wave digital data derived from it.

The idea is to write the train control packets into buffers using the .WAV format and play those via the audio port. 

Latency will still be an issue but if I can get to feed the sound card every 100ms or so most of the time that might be acceptable.

Fortunately gaps in the data stream are acceptable as the trains will continue according to the last received packet but too much delay will be frustrating to the user.

I am posting this information as others may be interesting in this scheme of getting digital data via an audio port.

John

engkin

  • Hero Member
  • *****
  • Posts: 3058
Re: NMRA DCC train control project.
« Reply #20 on: May 02, 2014, 11:53:59 pm »
Hoping you don't mind, I lightened the picture up a little bit. What OS are planning to use for now?

MrJohn

  • New Member
  • *
  • Posts: 22
Re: NMRA DCC train control project.
« Reply #21 on: May 03, 2014, 04:37:40 am »
I will be reverting to Windows.  I hope I can get acceptable performance.

John

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9776
  • FPC developer.
Re: NMRA DCC train control project.
« Reply #22 on: May 03, 2014, 01:32:28 pm »
The principle sounds better, since this can be done under DMA.  Some tips:

try a card with a hardware mixer. (like most Audigy cards).

PCI audio cards are really cheap in classifieds (I got one for Eur 7.50, trouble is only that PCI slots in PCs are becoming a kind of rare in equipment)   

Afaik Windows Vista and newer  comes with a software mixer by default (unless overriden by drivers), but I'm not really a sound man, I only occasionally here things.
Since software mixing might add extra latency testing with a hw mixer card and Windows XP on an old machine could be good to set a baseline, and you can see if you can get near with onboard chips.



MrJohn

  • New Member
  • *
  • Posts: 22
Re: NMRA DCC train control project.
« Reply #23 on: May 03, 2014, 09:50:09 pm »
I dont understand the advantage of a mixer.

Yes, setting a baseline is high on the priority.


marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9776
  • FPC developer.
Re: NMRA DCC train control project.
« Reply #24 on: May 04, 2014, 12:20:49 am »
I dont understand the advantage of a mixer.

Under Windows, multiple applications and system can generate sound at the same time and close to eachother. In older windows version conflicts were avoided using a first come, first serve mechanism (the first app got the soundcard, and while it was in play others were denied).

Later the concept of mixing started to emerge in higher end cards and became default/required in Vista+. Multiple applications can generate sound and their audio is multiplexed. Depending on hardware, this is done in software, which can cause delay/latencies.

 

MrJohn

  • New Member
  • *
  • Posts: 22
Re: NMRA DCC train control project.
« Reply #25 on: May 04, 2014, 03:59:11 am »
OK,  I can see that Marcov but I certainly do not want anything mixed with my 'sound'.

MrJohn

  • New Member
  • *
  • Posts: 22
Re: NMRA DCC train control project.
« Reply #26 on: May 04, 2014, 12:19:49 pm »
Hi, if someone can advise me please.  Is the Windows API the way I should be going for this project where I want to create sound files in software and play them in short buffers of 30 milliseconds or so?

Thanks

engkin

  • Hero Member
  • *****
  • Posts: 3058
Re: NMRA DCC train control project.
« Reply #27 on: May 04, 2014, 06:01:22 pm »
Is the Windows API the way I should be going for this project?
Yes. All what you need is in mmsystem unit. I would start with mono, 8.0 kHz samples, 8 bits per sample, and PCM format. For 30 ms, that means around 240 byte buffers. Most likely I would use a callback function to deal with the driver.

MrJohn

  • New Member
  • *
  • Posts: 22
Re: NMRA DCC train control project.
« Reply #28 on: May 04, 2014, 10:11:42 pm »
Hi engkin, thanks for your help especially as I am new to this area of software and I am not an easy learner.  It seemed really easy to write assembler code for the first micros nearly 40 years ago but now even the simple functions can be major achievements! :D

So far I have managed to play a file with sndPlaySound so some progress is being made.

I agree, mono 8 bit PCM and that is what I used to produce the waveform shown on my oscilloscope in the earlier picture but I really need to play at a sample rate of 17250 or 34500 or it horribly complicates the PCM code.  I hope I can get the sound hardware to do that.

John




 

TinyPortal © 2005-2018