I have put together a website the describes a way of detecting where trains are located by measuring the strength of WiFi signals: https://sites.google.com/site/wifiblockdetection/
Dang, that's a pretty cool application. Good job! I wonder if as a next step you could do some trigonometry based on the relative signal strengths and known locations and come up with a triangulated position vs. just saying I must be near the strongest one. To expand on that, you'd infer a relative distance from each sensor based on the relative strength of signal, estimate a triangulated position in space, and then compare that to the track diagram geometry and "snap" to the nearest segment of track to your estimated position. You should be able to get quite a bit more accurate and real-time with your positioning that way. I don't know if you are in school or not, but this could easily be an undergrad Senior engineering project, if not expanded to a Masters thesis. ETA: Doing some triangulation math would also mean you need fewer sensors for a large layout. This is basically how GPS works, except it's using timing instead of signal strength.
This is a really great addition to the DCCppESP32 project It also expands the capabilities for other usages beyond what you have currently implemented.
Heck yeah. That’s got great possibilities for virtual Sound decoder. I didn’t realize it could get that accurate. I’m gathering I could incorporate this into my Wemos D1 onboard decoders.. Must get back to modelling!
I fooled around with that a bit a few months ago. I found that the measured signal strength was not very repeatable for the ESP8266. Perhaps it will be better on the ESP32. Besides, the ESP8266 devices are so cheap. An Access Point could be constructed from an ESP-01 for less than 10 bucks, including the DCC to 3.3V conversion.
I made some significant improvements to the sketch. I got a modification approved for the ESP8266WiFi library that allows a scan of single WiFi channel. Rather than over 2 seconds / scan it now scans in 120 mS. I did not want to overload the DCC++32 server, so I only transmit an update every 500 mS. I noticed some dropouts in the measured signal strength at times, so now the same sensor has to have the largest signal twice in a row before an update occurs. I'll probably add an initial scan for the appropriate WiFi channel, since I am not sure if everyone would know how to figure that out. The sketch is located here: https://github.com/dtworth/ESP8266sensorScanner
I am very interested in this, getting ready to start a Garden Railroad and don't want to use block detection. I think this is a better application for outside.
While I think the less frequent updates is fine, if you switch from a TCP socket with the text protocol over to an http request you may see better throughput and it shouldn't slow the esp32, either way really. If you are able to break the esp32 code with too frequent of updates please log a bug so it can be tracked and hopefully fixed. Sent from my ONEPLUS A5010 using Tapatalk
I have not tried to identify the cause of this issue, but it does not cause anything to crash. At the 500 mS update rate, the command stream echoed from the DCC32++ system will stop responding for a few seconds every minute or so. However, none of the update commands are lost. It might not be the DCC++32 system itself -- it could be an anomaly in my WiFi router. I was trying to keep the communication overhead low so I did not think to try the http protocol.
The http protocol might work better as it can be a fire and forget model. The problem with network sockets is the esp32 can only handle so many before it has issues with concurrency. Sent from my ONEPLUS A5010 using Tapatalk
I created a new branch (https://github.com/dtworth/ESP8266sensorScanner/tree/FallerVehicle) to see if I can figure out how to control a Faller Road System vehicle. So far, I can vary the intensity of the ESP-01 on-board blue LED, so I should be able to control a transistor and drive the motor using that pin. I will probably add variable intensity to a couple of other pins so I can have tail lights for braking and turn signals. The remaining pin will be used for a sensor of some type -- initially the existing reed relay. I might need to beef up the battery since 2.4V is barely enough to reliably power the ESP-01. I am using one of the bigger trucks (https://www.faller.de/App/WebObject...g.en/ecm.at/Car-System-Start-Set-LKW-MAN.html), so I have some room to work with.
I now have this working using a custom circuit board. The Faller Road System trunk can now be controlled using a JMRI throttle. In addition to speed, I also control the turn signals/brake lights. This video shows the truck in action. The existing battery works ok, but I haven't tested how long it will last.
