Skip to content

Commit ba417bf

Browse files
CircuitSetupCircuitSetup
committed
v3.10
 - Play user-provided "ttcancel.mp3" if TT is cancelled through brake on Remote - Make TCD<->Remote communication more robust - P0: Fix speed-jumps on Remote when hitting brake (Remote and TCD firmware) - Speedo-less operation with Remote: Set TCD speed to 0 as long as brake is on. This prevents a time travel at 88 on the Remote with brake on. - Modify speedo-less time travel sequence if bttf clients are present or mqtt "publish" (regardless of enhanced TIMETRAVEL message) is enabled, and the tt is triggered by '0', BTTFN or MQTT (NOT: button): Now the sequence takes 5 seconds (as opposed to 1.4 seconds in prior versions) to give the props enough time for a proper acceleration sequence, and in case there is a ttaccel sound, it is played. As before, if the time travel is triggered by external button, it starts immediately and there is no acceleration-time whatsoever. - If a Futaba Remote control is present, it requires proper acceleration/deceleration and, in essence, acts like a speedo display; therefore, do TCD-triggered TT sequence as if speedo is present even if there is none. If the Remote is fake-off, only do that if it wants to display speed while off. - Add "Wireless (BTTFN)" speedo type. Allows using a simple BTTFN-listener as speedo. - Initialize everything speedo-related independent of speedo presence; if Remote is connected (later), it will require proper accel/deceleration sequence. See also changes of 11/24. - TCD-controlled TT while Remote is speedMaster: No TT while brake is on. If brake is hit while accelerating, TT(P0) is cancelled. - WM: Minor HTML tweaks; make page width dynamic for better display on handheld devices - Add support for MQTT v5.0 (tested with mosquitto only). Has no advantages over 3.1.1 (but more overhead), only there to use brokers that lack support for 3.1.1. - Add connection state info on HA/MQTT Settings page - Clear keypad input buffer when/after holding a key - Delete Remote/KPRemote upon forbidding remote (KP) control - WM: Require HTTP_POST for params save pages. Also, check if request has parameter, do not overwrite current value with null (protects from overwriting settings by errorneous page reloads) - Offer three purposes for TT-OUT (IO14): Time travel (as before), alarm, and control through keypad command; selectable in Config Portal. - Remove various compilation conditionals (FAKE_POWER_ON, TC_HAVELINEOUT, EXTERNAL_TIMETRAVEL_IN, EXTERNAL_TIMETRAVEL_OUT, HAVE_STALE_PRESENT, TC_HAVESPEEDO, TC_BTTFN_MC) - Add "stalled P0" feature for speed notification (used by Remote) - MQTT: Make "enhanced TT" default to on, it avoids the "5s lead problem". - Add (inter-prop) MQTT-"TIMETRAVEL" command with lead time and time tunnel duration attached, eg. "TIMETRAVEL_4950_6600". Only on bttf/tcd/pub. - Various fixes to inter-prop MQTT communication - Abort a network tt ahead of actions that result in a reboot - Add BTTFN_NOT_BUSY notification and status flag to inform BTTFN clients that the TCD is busy (eg keypad menu) and not ready for time travel. This is also used to transmit Remote(KP)Allowed stati. - Move HA/MQTT settings to separate config portal page - Allocate MQTT buffer only if MQTT is actually used - Re-order time_loop(): Handle timers in loop iteration following second change - Minor code cleanups - Put beep in flash now that there is space - MP3/File-Renamer: Ignore non-mp3 files; display number of files-to-do while renaming - Decode ID3 tags and free memory immediately on play-back start - Remove hack to skip web handling in on mp3-playback start, remove stopping sound in AP mode on CP access. - Block newly injected MQTT command while previous one is still being worked on. - Add MQTT command "INJECT_" - Add MQTT commands PLAYKEY_x and STOPKEY - Add commands 501-509 to play keyX (X=1-9) - Add option to disable time-cycling animation - WM: Generate HTML for checkboxes on-the-fly - Add "POWER_CONTROL_xx" and "POWER_xx" MQTT commands to control Fake-Power through HA. POWER_CONTROL_xx enables/disables power control through HA, and overrule a TFC switch if enabled. POWER_xx enable/disable fake power when HA has control. Command code 996 disables HA power control. Fake-Power through Futaba remote has priority over HA/MQTT. - Fix logic error in connection with "Remote fake power controls TCD fake power". Remote firmware 1.12+ will not control fake-power with 3.7. - New sound-pack: Includes sounds for remote on/off, and new night mode on/off sounds. (TW04/CS04) - [Broken in 3.7] Add "Remote fake power controls TCD fake power" feature. While Remote is Master, TFC switch changes are tracked but ignored. When Remote releases fake power control, TFC switch state becomes immediately effective. Configuration of this feature is done solely on the Remote. Requires firmware >= 1.12 on Remote. - Save beep mode when changed on-the-fly so it's restored on power-up. - Fix deleting a bad .bin file after upload - BTTFN: Fix hostname length issues; code optimizations; minor fix for mc notifications. Recommend to update all props' firmwares for similar fixes. - Restart WiFi power save timers after last BTTFN client has been expired - WM: Fix AP shutdown; handle mDNS - Send "REFILL" (009) to DG only, and via BTTFN, not MQTT. - Wipe flash FS if alien VER found; in case no VER is present, check available space for audio files, and wipe if not enough. - WM: More event-based waiting instead of delays
1 parent 9ec71f3 commit ba417bf

36 files changed

+4428
-2752
lines changed

‎AddOns.md‎

Lines changed: 123 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -208,11 +208,14 @@ For Rotary Encoders, see [here](#hardware-configuration).
208208

209209
### Connecting props by wire
210210

211-
The TCD can tell other props about a time travel. It does so by setting a pin (IO14, labeled "TT OUT" on Control Boards 1.3 and later) to high or low. "High" is between 2.7V and 3.3V.
211+
The TCD has a TT-OUT pin (marked "TT OUT (IO14)" or "IO14") which can be used to
212+
- signal a time travel,
213+
- signal alarm,
214+
- or manually switching on/off connected props.
212215

213-
![Wired connection](DIY/img/family-wired.png)
216+
Signaling is done by setting this pin HIGH (2.7-3.3V). Please do not connect third-party props without a relay; the TT OUT pin is not suitable for power supply. For connecting CircuitSetup/A10001986 props, see the prop's documentation ([Flux capacitor](https://github.com/realA10001986/Flux-Capacitor/tree/main?tab=readme-ov-file#connecting-a-tcd-by-wire), [SID](https://github.com/realA10001986/SID/tree/main?tab=readme-ov-file#connecting-a-tcd-by-wire), [Dash Gauges](https://github.com/realA10001986/Dash-Gauges/blob/main/hardware/README.md#connecting-a-tcd-to-the-dash-gauges-by-wire), [VSR](https://github.com/realA10001986/VSR#connecting-a-tcd-by-wire)).
214217

215-
You need two wires for connecting the TCD: TT_OUT (IO14) and GND, which need to be connected to the respective pins of the prop.
218+
You need two wires for connecting the TCD: TT-OUT and GND, which need to be connected to the prop.
216219

217220
| ![ttout](DIY/img/ttout.jpg) |
218221
|:--:|
@@ -222,43 +225,151 @@ You need two wires for connecting the TCD: TT_OUT (IO14) and GND, which need to
222225
|:--:|
223226
| IO14 on board version 1.2 |
224227

225-
Here's the timing diagram:
228+
#### Timing
226229

227-
1) Option **_Signal Time Travel without 5s lead_** unchecked
230+
Here's the timing diagram for a time travel signal:
231+
232+
1) Option **_Signal without 5s lead_** unchecked
233+
234+
If a time travel sequence is started by button and the TCD is doing the acceleration on the speedo, the TCD can calculate when the temporal displacement starts and notify other props 5 seconds ahead:
228235

229236
```
230237
|<---------- speedo acceleration --------->| |<-speedo de-acceleration->|
231238
0....10....20....................xx....87..88------------------------88...87....................0
232-
|<--Actual Time Travel -->|
239+
|<-Temporal displacement->|
233240
| (Display disruption) |
234241
TT starts Reentry phase
235242
| |
236243
|<---------ETTO lead--------->| |
237244
| |
238245
| |
239246
| |
240-
TT-OUT/IO14: LOW->HIGH TT-OUT/IO14: HIGH->LOW
247+
TT-OUT: LOW->HIGH TT-OUT: HIGH->LOW
248+
```
249+
250+
"ETTO lead", ie the lead time between TT-OUT going HIGH and the actual start of a temporal displacement is defined as 5000ms (5 seconds). In this window of time, the prop can play its pre-time-travel (warm-up/acceleration/etc) sequence. The sequence inside the temporal displacment follows after that lead time, and when TT-OUT goes LOW, the re-entry into the destination time takes place.
251+
252+
This lead time becomes a problem if you have a GPS receiver, a rotary encoder or a Futaba remote control and use either of those as a source for speed: A time travel is triggered upon hitting 88mph. In this use case, the TCD cannot know if or when a speed of 88mph is actually be reached and therefore not inform other props 5 seconds ahead. As a result, there will be a delay of 5 seconds from when the TCD's GPS/Rotary Encoder/Futaba Remote-induced speed hits 88mph until the temporal displayment sequence actually starts:
253+
254+
```
255+
|<---------- speedo acceleration --------->|<- waiting, waiting...........| |<-speedo de-acceleration->|
256+
0....10....20....................xx....87..88******************************------------------------88...87....................0
257+
|<-Temporal displacement->|
258+
| (Display disruption) |
259+
TT starts Reentry phase
260+
| |
261+
|<---------ETTO lead--------->| |
262+
| |
263+
| |
264+
| |
265+
TT-OUT: LOW->HIGH TT-OUT: HIGH->LOW
241266
```
242267

243-
"ETTO lead", ie the lead time between TT_OUT/IO14 going high and the actual start of a time travel is defined as 5000ms (ETTO_LEAD_TIME). In this window of time, the prop can play its pre-time-travel (warm-up/acceleration/etc) sequence. The sequence inside the time "tunnel" follows after that lead time, and when IO14 goes LOW, the re-entry into the destination time takes place.
268+
**** marks the certainly unwanted 5 seconds "stall".
244269

245-
2) Option **_Signal Time Travel without 5s lead_** checked
270+
2) Option **_Signal without 5s lead_** checked
246271

247272
```
248273
|<---------- speedo acceleration --------->| |<-speedo de-acceleration->|
249274
0....10....20....................xx....87..88------------------------88...87....................0
250-
|<--Actual Time Travel -->|
275+
|<-Temporal displacement->|
251276
| (Display disruption) |
252277
TT starts Reentry phase
253278
| |
254279
| |
255280
| |
256281
| |
257282
| |
258-
TT-OUT/IO14: LOW->HIGH TT-OUT/IO14: HIGH->LOW
283+
TT-OUT: LOW->HIGH TT-OUT: HIGH->LOW
284+
```
285+
286+
In this case, there is no lead. TT-OUT goes high when the temporal displayment sequence starts.
287+
288+
Conclusion:
289+
290+
If you are not planning on using GPS/Rotary Encoder/Futaba remote speed with your TCD, you can use the normal 5-second-lead technique if your prop is designed to play some kind of pre-time-travel sequence (acceleration, warm-up, etc).
291+
292+
Checking **_Signal without 5s lead_** is required if you are using a GPS receiver, rotary encoder or Futaba remote control as a source for speed, in order to avoid a "stall" when hitting 88mph. The downside is that other props do not get time to play any kind of "acceleration" sequence.
293+
294+
If you connect original CircuitSetup/A10001986 props by wire, make sure you set the option _TCD signals Time Travel without 5s lead_ in the prop's config portal accordingly.
295+
296+
### Synchronized time travel through HA/MQTT
297+
298+
Time Travel timing:
299+
300+
1) Option **_Enhanced Time Travel notification_** unchecked
301+
302+
If a time travel sequence is started by button and the TCD is doing the acceleration on the speedo, the TCD can calculate when the temporal displacement starts and notify other props 5 seconds ahead using the simple TIMETRAVEL command:
303+
304+
```
305+
|<---------- speedo acceleration --------->| |<-speedo de-acceleration->|
306+
0....10....20....................xx....87..88------------------------88...87....................0
307+
|<-Temporal displacement->|
308+
| (Display disruption) |
309+
TT starts Reentry phase
310+
| |
311+
|<---------ETTO lead--------->| |
312+
| |
313+
| |
314+
| |
315+
MQTT: TIMETRAVEL MQTT: REENTRY
259316
```
260317

261-
In this case, there is no lead. The time travel starts immediately.
318+
If you have a GPS receiver, a rotary encoder or a Futaba remote control and use either of those as a source for speed, a time travel is triggered upon hitting 88mph. In this use case, however, the TCD cannot know if or when a speed of 88mph is actually be reached and therefore not inform other props 5 seconds ahead. As a result, there will be a delay of 5 seconds from when the TCD's GPS/Rotary Encoder/Futaba Remote-induced speed hits 88mph until the temporal displayment sequence actually starts:
319+
320+
```
321+
|<---------- speedo acceleration --------->|<- waiting, waiting...........| |<-speedo de-acceleration->|
322+
0....10....20....................xx....87..88******************************------------------------88...87....................0
323+
|<-Temporal displacement->|
324+
| (Display disruption) |
325+
TT starts Reentry phase
326+
| |
327+
|<---------ETTO lead--------->| |
328+
| (5000ms) |
329+
| |
330+
| |
331+
MQTT: TIMETRAVEL MQTT: REENTRY
332+
```
333+
334+
**** marks the certainly unwanted 5 seconds "stall".
335+
336+
2) Option **_Enhanced Time Travel notification_** checked
337+
338+
If a time travel sequence is started by button and the TCD doing the acceleration on the speedo, the situation is as above: The TCD can calculate when the temporal displacement starts and notify other props 5 seconds ahead - and actually tell those props when exactly the temporal displacement is expected to start:
339+
340+
```
341+
|<---------- speedo acceleration --------->| |<-speedo de-acceleration->|
342+
0....10....20....................xx....87..88------------------------88...87....................0
343+
|<-Temporal displacement->|
344+
| (Display disruption) |
345+
TT starts Reentry phase
346+
| |
347+
|<---------ETTO lead--------->| |
348+
| (5000ms) |
349+
| |
350+
| |
351+
MQTT: TIMETRAVEL_5000_yyyy MQTT: REENTRY
352+
```
353+
354+
Now, again the GPS receiver/rotary encoder/Futaba remote control scenario:
355+
356+
```
357+
|<---------- speedo acceleration --------->| |<-speedo de-acceleration->|
358+
0....10....20....................xx....87..88------------------------88...87....................0
359+
|<-Temporal displacement->|
360+
| (Display disruption) |
361+
TT starts Reentry phase
362+
| |
363+
| |
364+
| |
365+
| |
366+
| MQTT: REENTRY
367+
MQTT: TIMETRAVEL_0000_yyyy
368+
```
369+
370+
As you can see, there is no stall: The props receive proper info on when the temporal displacement starts - in this case immediately (0ms).
371+
372+
Conclusion: If you are not planning on using GPS/Rotary Encoder/Futaba remote speed with your TCD, you can use the normal TIMETRAVEL command. In the other case, you need to teach your MQTT-aware device how to interpret the enhanced TIMETRAVEL_xxxx_yyyy command. Both xxxx and yyyy are always four digits. xxxx is the time until temporal displacement starts, yyyy is an approximation of the duration of the temporal displacement; however, don't use this value to time the reentry, instead wait for the REENTRY command to initiate your re-entry sequence.
262373

263374
---
264375
_Text & images: (C) Thomas Winischhofer ("A10001986"). See LICENSE._ Source: https://tcd.out-a-ti.me

‎CheatSheet.pdf‎

4.23 KB
Binary file not shown.

0 commit comments

Comments
 (0)