|Freerails IS ACCEPTING new Members ... To join Freerails ... See how to Register as a Member in the 'Joining Freerails' Forum|
|Moderated by: .|
I would like to introduce a program that I'm developing at the moment.
It is used to program DelTang receivers using the Prog4 programmers comfortable on your computer.
The program is "Open Source" (source is included in the installer package),
and is released under the "GNU GENERAL PUBLIC LICENSE Version 3".
In addition to a Windows PC you need (of course) a Prog4 plus a serial to USB cable to connect the Prog4 to the PC.
And of course the "DT-Programmer" software which can be downloaded from my blog, or the link below.
Just click the link at the end of the article to download the program.
After downloading, open the zip archive and run the file contained therein.
With the help of an ordinary installer "DT-Programmer" is installed on the PC.
That should be possible to everyone.
After installing DT-Programmer you should first connect the Prog4 to the PC.
Under certain circumstances, drivers for the serial to USB cables need to be installed.
This is necessary so as these cables create an additional COM port on the PC.
This COM port must be selected in the DT-Programmer.
But it will only be displayed if it exists.
And that is only the case if the cable is plugged in.
On top of the receiver to be programmed must first be bound to the Prog4,
exactly as it otherwise is done with the transmitter.
For this, the Prog4 has a sideway "Bind button".
Actually, the receiver should remember that they (also) are bound to the Prog4.
However, it is repeatedly happened to me, that the RX "forgets" about the binding.
The program is running in English and German language,
and can be translated easily into any other language.
All used terms and vocables are external stored in an ".lng" file,
a simple text file that can be edited with notepad or similar by everyone.
On very first start you need to do a little configuration.
For this you need to select the "configuration" menu entry on the top of the window.
Here another window opens where you can do the needed configuration:
The GUI- language should be set to your preferences.
You also need to select the COM port where the Prog4 is connected too.
That's why the Prog4 should be connected at first start.
The baud rate depends on the version of your Prog4.
The older V1 needs 115200 baud and the recent V2 needs 9600 baud.
So you need to know which version your Prog4 is.
Once you're done you need to save settings and restart the program.
A requester is telling you about the need to restart the program after clicking on "Save".
Save the settings, close the program and restart it again, now you can start programming.
The window is similarly structured at each point.
The right part is always the same.
The first step always is to connect the program to the COM port.
In the right area of the main window there are buttons to connect and disconnect, to test the connection
(that gives the version number of your Prog4 as response) and to manually program a feature.
This is useful for new and not yet included options.
You only need to type the correct sequence, eg. "7,2,7" to change the variant of a V610 receiver to "22 - Train with Selecta".
After clicking on connect, the logo in the top right corner changes from red to green, if the connection was successful.
The text field in the lower right area is the response window, and displays all messages send from Prog4 back to the PC.
If you test the connection and everything went well, a message similar to the one on the screenshot should be appear.
Normally you should disconnect the COM port when done.
For this the disconnect button is available.
On a clean exit of the program the connection is closed properly too,
so it did not matter if you forgot to close the connection...
Once the connection is established you can start programming your RX.
You need to know the firmware version of your RX.
Sadly there is no way to read the firmware from RX with Prog4,
so you need to select the matching firmware version manually.
If you don't know the version of your RX you need to have a look on it.
The firmware version always is hand written to the biggest chip on the RX.
If you know the matching firmware you need to select it in the top row.
Then the navigation bar may change, depending on the number and type of options the selected firmware has.
Most options are on V611 least are on V110...
The navigation buttons are representing more or less the menu structure as shown on the DelTang website.
Some menu entries are holding very few others have many options to program.
So some of those "too many" options are changed over to a different menu.
Especially some "LED" options are transferred to the "Infrared" menu in "DT-Programmer".
But I'm sure you will find then, if you want to change them...
As the vast majority of DelTang RX only accept one command at a time, you need to write every command one after the other.
For this you only can select one option at once.
Set your values for the first option and click "Write".
After the "OK" response of the Prog4 select the next option, set the next values and "write" again.
And so on, and so on...
This way it is working on every window excerpt for the "Reset" menu.
Here are more than one Button as here are completely different options are bundled.
This menu also changes a lot depending on the selected firmware.
Here it is for V611:
You see three buttons. For V610 it looks as:
Here are two buttons available.
Aside this exception all windows only have one Button...
I think you will have a clue now how it works.
At the current state V110, V510, V511, V520 and V610 is supported completely
(I hope) and V611 also is complete excerpt for Menu 12 and 13 (as on DelTang website).
In general everything that is not greyed out should work.
Finally the download link:
Thanks for reading,
Thank you for this.
I only have one DelTang right now and no Prog4,
but I appreciate the effort you have put into this.
It should be a real boon to users of DelTang equipment.
I know I will probably pick up a Prog4,
just so that I can easily make changes.
I do have one question.
Since the Prog4 cannot read the receiver firmware,
does your program allow you to store a copy of your settings in a file,
so that if I go back some months latter to reprogram one of my receivers,
I can reload what my settings were for that receiver?
I'm thinking of things like custom start voltage, etc.
that I may want to tweek again at a later date.
|Tom Harbin wrote:
The Prog4 is not like a DCC decoder programmer.
You cannot set a bunch of settings and send them with one mouse click.
The vast majority of DelTang RX only can handle one command at a time,
so you need to send every single setting separately to the RX.
Aside from this, you cannot read any settings at all, from the RX.
The programming options are not stored in any way,
so there are no "decoder settings" I could save to a file.
If you later want to know which options you've programmed to a specific RX,
you need a sort of RX- database.
This will definitely need some manual work, as nothing can be read from the RX itself...
Right now there is no database- alike function included in DT-Programmer software.
This is a possible improvement later,
but I first need to think about if it's worth the effort.
And if it will be implemented I need to think about the way to do so.
Personally I wasn't in a need for this function up to now,
so I'm not sure how to implement it in a useful way.
Some RX have a huge amount of options, to catch them all will be a lot of work.
Let me think a bit before I decide,
if I will implement something like a RX (or Loco) database into DT-Programmer...
I was thinking of something like a simple text file or maybe XHTML.
Dump the settings from the various pages in your program,
to a file that we could name (like On30 Porter #4.prg4).
Then if I could read it back into the programmer,
I would see what I had saved last time.
More like a centralized memory refresh (mine not the software's).
Let's see, what did I set for start voltage on that Porter,
was it 1 volt or 1.2 volt, what did I do with that hunk of paper.
It wouldn't be used to set values,
but rather to remind you what you had already set.
Since you can't bulk load nor read in the receiver,
I figured that for the guys that have lots of engines,
it would give them a way to easily recall,
how they had already customized a particular receiver.
Just a thought.
Actually it might be even more useful,
to just keep a log for a receiver session.
Log to a text file the actions saved to the receiver.
Even better if it included plain text of the sequences meaning,
as well as the actual values entered,
but then of course you get into language issues.
So if you took a receiver and changed it from a -2 to a -22 variant,
it would record the RX Version you had set,
and the change from -2 to -22.
No need to store it in a database or automate it,
just record a text entry for each save action to a text file,
and have the option to save out the file.
No need to read it back in,
just open it with your favorite text reader,
to see what you did.
A logfile surely could be implemented.
And most likely I will start implementing this next week,
as I think it's a good idea.
Is it useful to ask the user for a specific name for the log file?
This could be annoying I fear.
But without, you need to write down the date and time by hand,
when you've programmed a specific receiver.
If no manual name is given,
the logfiles most likely must be saved only with date and time, as file name...
Tom Harbin wrote:
This can't be done exactly as wanted,
because there is no way to know which variant was set before.
I only can log the change to variant 22 itself.
But is it important to know what it has before?
And of course, I can log which menu item (aka which firmware version),
was used for this RX...
The type of the RX itself (e.g. RX61 or RX 47) I can't log,
as the program doesn't know it.
In meantime I also like the idea of a model-database in DT-Programmer.
So probably I also will implement this.
But this definitely will take a lot of time before something is ready to use.
And I first need to have a look on some other model-databases,
to see how they are structured, just as an inspiration.
No it is not important what the previous setting of a field was.
Your suggestion of just saving the new setting was actually what I was trying to express.
I just didn't say it very well.
I think that saving the firmware version from the selector
(since we assume the user looks at the chip and sets it to the right selection when they start)
and the actual field value saved to the receiver, is all that is needed.
Date-time only is probably okay,
but I just figured that no database would really be needed,
if the user could easily find the log files from a particular receiver.
Of course, this assumes the user comes up with a naming convention that makes sense to them.
I would probably do something like - Porter#3-20191006-102155.txt.
Basically just some easy way to separate one receiver's files from anothers.
Maybe you could add an optional text only field near the top of the main form,
where they can enter a description if they want to,
that is appended to the beginning of the logfile name, if they chose to enter it.
If they don't enter it, they get a date-time stamp filename.
If, in my case, I entered "Porter#3-" in the field, I would get one like above.
I don't see any of this as "needed",
but rather taking what already appears to be a very useful new tool,
and making it even more useful for those of us that would use it on an occasional basis.
By the way Claus, I went out and read your blog.
I especially liked your posts on your CNC machine and the Kitwood Hills turntable.
I also had never heard of the coreless motors you referred to in one of your engine threads.
I checked them out.
Thanks for your kind words about my blog.
So it looks as if the automated translation at least is understandable.
Here is a link to the tramfabriek website.
It's a Dutch company (more or less a one person company) based in the UK.
That's why orders are shipped from UK.
They mainly are selling H0e Tram Locos and similar stuff,
but also have a bunch of coreless motors.
The coreless motors they are offering are very cheap,
compared to Maxon and Faulhaber motors.
For everything up to small 0n30 Locos the motor is powerful enough.
And it is running with an equal quality to Faulhaber motors.
Bigger locos most likely need more powerful,
and for this more expensive motors, from other companies.
I originally had problems with Prog4 using CoolTerm,
and tried your program with equal lack of success!
Subsequently I changed the Baud rate, and got the correct response.
(There is a label covering the back of the Prog4, sealed within shrink wrap).
However, writing the changes get an OK response,
the changes are not effected to the Rx.
I have Rx 105 controlled through 2 MUX boards.
and I am trying to change pins 3&4 (1,3,1,6) and (1,4,1,4).
I am getting 3 flash on Prog4 and Rx,
so wonder what I have missed.
Do you have any suggestions, please?
Geoff L wrote:
It seems you have an "old" Prog4 (version 1).
Then you need to change the Baud rate from 9600 to 115.200.
This is a normal thing and for that the two different values are to select...
If you later will get a "new" V2 Prog4, you need to change this back to 9600...
Geoff L wrote:
The only thing I can imagine is, that the binding between the Prog4 and the RX,
has not worked or the RX has "forgotten" the binding to the Prog4.
If the Prog4 responds an "OK" everything went fine on the PC/Software side.
As the Prog4 can't read (opposite to DCC) anything back from the RX,
it only can check it's own work, not what's happen on the RX side.
If anything worked properly on the Prog4,
the only remaining issue area is the communication between Prog4 and RX.
Most common are binding problems,
but it also can be a hardware issue with the adapter cable (not very likely),
or a defect on the Prog4 or Rx side...
This is possible as you also don't get a result if you are using CoolTerm.
So an issue on the software side, is close to impossible, IMHO...
Aside this I never had my hands on any RX 105 myself (I only have RX 6x receivers),
so I can't try to reproduce the issue here.
But I don't believe it is a software issue at all,
so even if I had one, I don't think it would help in any way.
Thank you, Claus.
I was not being critical - your program is very easy to install and use.
I thought I had solved the problem thinking about your reply,
and discovering I had possibly muddled the two tables of channel numbers,
for the 5 channel and 7 channel versions.
However, I have not managed to change functions on two Rx105s,
and am assuming the problem is with the cable or the transmission.
Are you ever able to change any setting on your RX 105 with your Prog4, no matter if it was with CoolTerm or DT-Programmer?
If yes, the cable and hardware should be ok and the issue most likely is the binding between the Prog4 and the RX 105...
If not, the issue may be on the hardware side (cable, Prog4 itself, PC)...
One thing I like to mention too.
If you've connected the Prog4 to your PC via an USB Hub then please try to connect it directly to one the PC's own USB Ports.
It happens really often that the Prog4 did not work properly if you connect it to an USB-Hub...
I think I've found a nice way to incorporate the programming protocol as you suggested.
It even is localized.
The User sets a name (e.g. the Model type or whatever it should be),
and DT-Programmer writes all programming steps into a protocol file with the given name.
If no name is specified a default name "protocol" is used.
In this file all programming steps are logged with date, name and value.
This file will stay "forever" and new programming steps are added at the end.
The selected firmware also is logged.
And the user can select, if he wants the protocol or not.
And he can also start a new protocol file by entering a new name.
I was busy developing this and now I have it build in for V611 firmware.
The other firmware versions I still need to add.
But I can send you a test-build with only V611 protocol working,
so you can see if it is as you wanted it...
Everything else is working as before, so it should be no big issue to test it...
Here is the link to the new version, where the protocol option is included.
It is working with any firmware but the protocol only is complete with V611 up to now...
Now the protocol is completely included.
You can set a name to use for the protocol in the top right area above the “connect” button.
This can be whatever you like, but it would be best to choose a meaningful name,
e.g. the name and type of the model and the RX.
If you don’t set a name, the protocol will be named “protocol.txt”.
A protocol file will be generated on first programming step in a sub- directory of the installation folder named “RX”.
The protocol files are plain text files and can be viewed with Notepad or any other text viewer/editor.
You also can opt to not generate a protocol at all,
e.g. if you are programming other peoples RX or similar.
Once a protocol file is generated, all future changes will be written at the end of the existing file,
if you choose the same file name as before.
In a later version, DT-Programmer will include a protocol manager to view and delete protocol files.
But this will take it’s time to complete.
Up to then you can manage the protocols easily with Explorer or similar tools.
Here is the direct link to the download of the new version:
That looks really good,
and is everything I could have asked for.
Unfortunately, it looks like it will be a long time,
before I'll be able to pick up a Prog4 to try it out.
Congratulations on your 'DT-Programmer Software'.
I am sure that it is a great resource for DelTang R.C. users.
However there is a problem.
The photos, which are an essential aspect of describing this, are not appearing here.
If I don't see photos in this Thread, then many others will not see them either.
We have had endless problems on the Site, with missing images from 3rd party photo hosts.
This problem, which is obviously nothing to do with Freerails, makes these Threads useless.
We constantly, to the point of tedium, appeal to Members to upload their photos to Freerails.
It is then absolutely certain, that everyone trying to look at Threads on the Site, can see images.
PhotoBucket recently making huge amounts of content on the Site useless is a serious problem.
Despite Members being well aware of this fact, photos are still being Posted from 3rd party hosts.
In the wake of the PhotoBucket fiasco, some Sites are refusing to except Posts with 3rd party content.
We are currently trying to deal with this & other 3rd party hosting problems on the Site.
This is simply to ensure that both now & in the future, users can actually see a complete Posting.
We would like content seen on Freerails to be 100% reliable, which with 3rd party hosts it isn't.
The missing photos in this Thread really need to be uploaded & Posted from the FREE Members 'Gallery'.
This ensures the Thread is 100% reliable & all images are there for users to see.
The screenshots are hosted on my own blog,
not on a picture hosting service.
And they should be visible everywhere, incl here.
For me they are for sure. Nothing missing here.
I have posted them in many forums and they are visible everywhere.
I will see, if I find the time to upload them to the Gallery,
also I don't see them as that important.
But I first need to grab new screenshots before I can upload them,
as I don't kept the ones that are posted.