First WiFi Loco-Nodes, ready for fabrication/assembly

ModelRailroadForums.com is a free Model Railroad Discussion Forum and photo gallery. We cover all scales and sizes of model railroads. Online since 2002, it's one of the oldest and largest model railroad forums on the web. Whether you're a master model railroader or just getting started, you'll find something of interest here.


Status
Not open for further replies.
Things seem to be moving ahead. You need to build a small test box with pins so that you can drop those modules in it and test without having to solder your wiring harness in place. Just my $0.02.

I am watching your progress with interest. Moving to all wifi and batter power is very appealing.
 
Things seem to be moving ahead. You need to build a small test box with pins so that you can drop those modules in it and test without having to solder your wiring harness in place. Just my $0.02.

I am watching your progress with interest. Moving to all wifi and batter power is very appealing.

JOOC how many locos do you own? How many are going to have room for that receiver and battery?

If you had a large number of locos, say 50, how would you keep them charged?

Wifi? Yeah pretty cool.

But battery power when you've got metal rails just sitting there ready to deliver power? I dunno.
 


WiFi is cool, but I think the interface is going to be the killer. "Kids" are growing up with smart phone interfaces. An NCE powercab controller that seems "natural" to you or I is an alien object to the next generation of MRR people. Giving them a smartphone interface will make the leap into controlling MRR seamless.

As for battery, I can use the rails to charge the battery... now who really cares when track is dirty or about those tricky turnouts (leave them un-powered), I only really need the area that I park the train in at the end of the session to have power.

These are all good things in my mind. The problem is that someone needs to come up with a good set of standards so that engine, decoder and controller companies are not competing for market share based on vendor lock-in.

Wifi? Yeah pretty cool.

But battery power when you've got metal rails just sitting there ready to deliver power? I dunno.
 
I just caught up on this thread and I want to say that I think you are doing amazing work! I certainly feel that this is the future for model railroading. Wifi is getting popular in the RC fields and this is the next natural step IMO. Looking forward to seeing the progress.
 
Things seem to be moving ahead. You need to build a small test box with pins so that you can drop those modules in it and test without having to solder your wiring harness in place. Just my $0.02.

I am watching your progress with interest. Moving to all wifi and batter power is very appealing.

The first 8 boards I am testing with, I found a cool way to keep the pins in place is put a large white eraser under the board.

The last 7 boards of this batch, I will use clips for the battery connection to preserve the pads so there will be no soldered connections on them (we can ship that way). The next production batch will be flashed at the factory so they will be ready to go when they arrive.
 
WiFi is cool, but I think the interface is going to be the killer. "Kids" are growing up with smart phone interfaces. An NCE powercab controller that seems "natural" to you or I is an alien object to the next generation of MRR people. Giving them a smartphone interface will make the leap into controlling MRR seamless.

As for battery, I can use the rails to charge the battery... now who really cares when track is dirty or about those tricky turnouts (leave them un-powered), I only really need the area that I park the train in at the end of the session to have power.

These are all good things in my mind. The problem is that someone needs to come up with a good set of standards so that engine, decoder and controller companies are not competing for market share based on vendor lock-in.

The Loco-Nodes 0001 and 0003 have the Li-PO support, Loco-Nodes 0002 and 0004 do not, so they need constant track power like a decoder.

As for vendor lock in, our system is good for iOS, Android, Windows, and Linux. Where I can see the issues in the near future is do they use C# as we are or JAVA. Both have advantages in some areas but I think C# is going to be more flexible for multiple O/S.
 
So far all power supplies on the boards are good. That clears 50% of the systems.

I am able to establish a UART connection to read the RX/TX events from the CPU. This means the CPU is working.

It is also going into USB Recovery Mode which enables the flash to be written with a USB connection.

The hold up now is waiting for a manufacturer response on the Software for this function so I can set it up correctly and it recognizes our type of NAND Flash IC.

Here is the test set up up:

1109371072423377_4266750073934040463_o_zpspjuvd90c.jpg


Here is the COM8 (USB Connection) and COM9 (UART Connection) - both are working

1109375509089600_2219561590639808749_o_zpswxwepvnx.jpg


Here is the PuTTY (COM9) showing the UART events from the board.

1109375495756268_2499273579221349771_o_zpsyp0b6gxn.jpg


If I can get the software for the USB configured, it needs a NAND ID which I am trying to figure out, it will not take long to test the pins on the CPU and remaining systems.

So far everything is working perfectly for the hardware, of course, with this being the first board to get up and running, its a learning curve.

The software we have ready to flash it with though is enough to run with so it will be a downhill jog once I get the answers I need.

The only real area of new territory will be the new motor control, it runs totally different using the new driver as it takes phase/enable input versus PWM.

Christopher Howard, Layout-IoE
www.layout-ioe.com
 
I received a bunch of info last night to action.

Juan is going to create the Bootable SPI NAND file I need by tonight.

In this screen shot, we can see the CPU is seeing the SPI Flash but it doesn't have a file and ID # because we haven't made one yet.

So this isn't a hardware hold up and it verifies the SPI Flash is connected OK.

I have a few things I need to get set up today for the programming software but if we get the SPI file ready tonight and loaded, this clears the CPU and we can also test the WiFi antenna tonight. It should work right away when the file is loaded.

IMG_20150415_080657_zps0jww8spt.jpg
 
I did a bunch of electrical checks and cleaned up the programming set up.

The Flash Writing software isn't going to work with bare metal so we're going to use either Das U-Boot or RedBoot. Just waiting for Juan to get back to me with a boot file and a copy of the firmware. All of the hardware for the CPU is doing what it should. So we're in great shape, just impatient to get this loaded and moving.

I also go an updated file on the UX. A lot more is working now.
 


Great news this morning!

I remade a new USB cable and made sure it had no chip inside so its raw.

After I connected this, Windows now detects the flash memory and so does TurboWriter.

So we can now flash the boards once I get a file from Juan.

This clears the CPU as good and the SPI Memory.

The last parts of the board to clear is the antenna, motor driver, speaker amplifier, FX_LED, and motion sensor but well over 60% is now tested and functional.

Christopher Howard, Layout-IoE
www.layout-ioe.com
 
Hi,

I pulled out a second Node without the jumpers soldered to it for this set up, this enables flashing of the samples without leaving marks on them.

1111044622256022_7124691697147207809_o_zpsg3w4iq2h.jpg


Here is the USB connection to Windows and message it generates. Now after much fiddling, we have a working connection and the Windows app for flashing works.

USB_BOOT_zpsgkqmbtzk.png


Juan is sending a file late tonight or tomorrow morning to flash with and get the WiFi antenna working next.

Christopher Howard, Layout-IoE
www.layout-ioe.com
 
Hi,

Did a bit more work on the connections, an engineer verified the boards with me. We are 100% ready to load an image tomorrow. Will be able to mount on the SD70 Sunday night.
 
Here is what I have fighting to set up this week:

SPI_1_zpsdwqsuk35.png


SPI_2_zpsqq9zboqv.png


To get the above, the UART RX/TX event log must work, the board must work, the CPU has to boot and go into USB recovery mode, and then Windows/Flash Writing Software must be able to see the memory and access it.

Woke up to a dead Li-PO. The clip contacted one of the pads through the electrical tape below where I placed the UART Ground connection at VOLT_N1. If I had to, a dedicated UART Ground would have been added but its not needed. Some card stock will prevent this from occurring.

Remade the connections again and everything works.

I got a second dead battery trying to diagnose the issue.

I have another Node that I used to recharge the two dead batteries. Worked excellent.

The power supplies all stay up during recharge so if you have dead track, just add a few areas of power for recharging. You can run while recharging.

The batteries stay cool, the board gets warm but there is battery fault and over temp protection in the battery charger. The batteries also have a PCM, power protection module. This prevents over charge, over current, over voltage, and balances out the cells.

YOU DO NOT have to take the batteries out of the locomotive for recharge.

So consider this a SMART HYBRID LOCOMOTIVE. The CPU for the system is in the locomotive where it should be.

Waiting on Juan to wake up, must have had a great night.

Christopher Howard, Layout-IoE
www.layout-ioe.com
 
Be careful with a fully discharged LiPo - they don't take kindly to a full discharge and can actually be damaged.
 
It took a day to recompile our firmware into the correct format.

We tried to flash but the software is not sending the packets so something in the flashing software is not configured right even though it can access the memory for reading.

Sent off a support request, we should get a response tonight.

Capture_zpsonnzw4ma.png


I did recharge three dead Li-PO's yesterday while waiting.

The battery charge reads the battery voltage, and if it's dead, deep cycles it. I got full charge in just under two hours on a 7.4V, 1350 mAh battery

The board was warm at first, after a while though it cooled as the charge rate slowed near the end

With normal batteries, the boards will remain in a very comfortable range, not getting hot enough with a dead battery to say just let it charge, don't run but I would keep an eye on it just to be cautious if you put in dead batteries.
 
working on some solutions

a) we can flash using Linux as the memory shows up as a USB drive, so installing Virtual Machine to test

b) we're working on a boot-loader file as the one supplied by the manufacturer will not work with our hardware

[video=youtube;iZ3-70GGg28]https://www.youtube.com/watch?v=iZ3-70GGg28&feature=youtu.be[/video]
 
I got a partial victory today, using the online instructions, I was able to get the Linux O/S burned to SDRAM and open a console

Waiting on a response from two sources on how to set the addresses needed to read/write the SPI FLASH

We're starting to turn attention now to the boot file creation

Juan will play with the console tonight, we can test/check and configure a lot of the board from the console

CPU_zpsuaycmnit.png
 


Back and forth from the manufacturer of the CPU - been trying to get the settings to do SPI Flashing

Juan got into the console and confirmed the CPU is good

Now we can load new files to test the remaining systems and enable individual GPIO while we compile a boot system
 
Status
Not open for further replies.




Affiliate Disclosure: We may receive a commision from some of the links and ads shown on this website (Learn More Here)

Back
Top