Ok so on further investigation the app is not responding at all. When i go to connect the bluetooth via the settings/bluetooth connections i can see the teltail in the detected connection available. When i select it i get “connection refused by teltail”. And it remains on my list of available connections and unconnected.
When i open the app it is frozen and I can’t select any buttons or menus. After a short while android will pop up an “app is not responding” with a wait or terminate options. If I choose wait it just sits frozen until I leave focus and pops the same msg if I return to the app
Thank you for reporting this. Has the app connected in the past and this just started? Or is this happening on your first attempt to connect? I have not seen this issue before so I do not have an immediate solution, but this gives me some insight into how to debug.
Can you also tell me what android version & device you are running the app on?
There was an issue with one of my devices connected destabilizing the can bus connection and I haven’t finished rebuilding around omitting it yet to retest the ttl.
I have connected to the ttl module with the app previously but that was with a different uart and can bus arrangement on a test bench on a different phone… so im just putting a pin in it for the moment until i can finish getting everything else connected and connected reliably.
With the economy in shambles im down to only working 60hrs a week lol. I swear the news cycle is completely ignorant of what is actually happening in seattle. Seriously though I should be able to get some time in the next week to take another crack at it
Ok so I messed around a bit and was able to get the bluetooth to say connected when opening the app. Attempting to read or write the first time made it time out. Sent a crash report and got this msg on screen:
So i got it sorted! Something about the device i was using just didn’t like the ttl and a fresh install on a different device got it up and running!
Now question time @Ricco: i seem to be missing something with the remote on input settings. Only having the ttl uart connected to the vesc, can i use the remote (hoyt puck) break tap control setup? Or do i need to have the pwm signal from my receiver terminated to the ttl also?
Ok, so then i should get a state change when using the “flick the brake “ input option? Current I only have the txrxgnd three pin, 12v in, and left&right rgb led connections. I get good response from the leds as far as the ttl accelerometer goes in x and y modes. As well as rpm mode.
What should i be looking for beyond following the published instructions for remote setup?
Sorry I am not much help, in the setup process in the app you choose if you have a remote I think. I honesty forget how it works. We will be informed of how soon here I bet.
Hey @Pecos, it is good to hear switching devices resolved your app connection issues. For the throttle based control of the TTL system, it should work for you with your current setup. You will just need to set the Remote Config menu as I have it below.
After writing those settings, you should be able to turn on/off the lights with a flick of the throttle downward. If the lights dont turn on/off, try increasing the duration the brake is applied. If still doesnt work, a good sanity check to perform is to check that the value for Remote X changes with the throttle on this screen.
Thanks for the breakdown, i ran into the same problem as before where the app has stopped connecting or is rejecting the connection. The app seems to stall if i try to connect with bluetooth turned off then never recovers? Haven’t nailed it down yet but the previous bug report is probably still valid.
Im going to try again tonight and go through my troubleshooting process again otherwise im going to find another device and see about getting the settings dialed before i log off of it so i can just leave it in a set and forget.
Btw a friend of mine wants to mess with the ttl and see if he can make some custom modes and mess with the addressable led modes and such, how opposed to the moding community are you on this? He was looking at the files on gethub and salivating saying he thinks he can make a more feature rich custom setting. It’s all beyond me, im more of a hardware side experience level but it sounds like a fun project to learn on. Might have to get a second one to experiment on XD
Sorry for not responding in a while. I have been very busy and have not been able to find time to follow up on your issues. I expect to have some time this weekend for some debugging though.
Thanks for all the info you have provided. It is very helpful for trying to recreate the scenario on my side.
Since I believe I recall you are using a dual ESC, can you verify that the TTL is communicating with the ESC side that the remote’s PWM is going to? Regarding the app readout, I mixed it up and Y is the axis that should be moving, but I do see from your video it is not changing either. That could also happen if the remote throttle input type is not set to “PWM” in the TTL settings, but I believe you checked that after my last response.
Regarding the TTL app’s remote feature not working, I believe that is caused by an incompatible motor control setup on the ESC. I will have to play with the latest FW and determine what settings are compatible and incompatible with the TTL app remote. That way I could specify the compatible setting on my site.
Regarding your friend’s interest in tinkiering with the code, that sounds great! That’s exactly why I had published the code on github in the first place, but just never got any interest from users to edit the code. I admit I dont really know how to use Git properly for merging changes from other contributors into the master, but I definitely willing to learn if anyone has changes they want to propose.
No worries about the response time, no apologies necessary.
The ttl and pwm remote are connected to the same esc (secondary one btw). There may be underlying issues with the esc firmware so i am going to do another test.
The ubox 5.3 and 6.0 firmware have stability issues and threw me, and in the last tumble i damaged my puck and have to repair the pot (parts just got in today). Followed some good advice from havenever and rolled back to 5.2fw and it seems to be significantly more stable so im going to retest everything once I’ve got the puck back together. I think the 5.3 fw is complete garbage and the 6.0 fw seems more predictable to a point then is resetting to default settings randomly and dropping out one vesc fsr basically rendering it dangerous to use.
If it wasn’t for havenever running basically the same setup for months now on 5.2 stably i would have just shitcanned the ubox. Fool me once kinda deal.
Im meeting up with my friend to hash out a game plan Friday. a really powerful custom mode is what id like to work on with him - I noticed that in the custom mode x axis reaction with a constant color output, the brightness of the leds is static (on or off and not proportional to the amount of x acceleration). This was one of the things he was going to look at and see if we could tweak it a bit to make it more dynamic and possibly see if he can come up with a method to incorporate addressable led outputs with this type of mode.
are there any specific roadblocks you ran into that prevented you from having a splash carve mode with the addressable strips? I am super novice, I don’t understand the systems well enough yet to know what is feasible or not
@Ricco i ran into something weird, using the usplit - ttl, metr, davega plugged into the secondary ubox uart port ( primary ubox uart is turned off when using the built in controller receiver) 12v power is disconnected and not provided to the ttl and my led strips turned on when I powered up the esc. Is the uart power connection back feeding the leds? Could the usplit be providing power to the ttl and back feeling the led strips?
Because the remote switch and reverse throttle flick and app aren’t working i was attempting to control the ttl on/off state by switching the 12v on and off. If that’s not a valid control scheme im kinda lost here. Any ideas on how to control this thing? Im tearing my hair out trying to get any one thing to work.
I can provide a momentary 12v signal, use your fob type relay, or provide a latching 12v signal. My preference would be to use a momentary 12v signal to control the module but I don’t see how to go about it
This may be a setup issue specific to the ubox since I have tested on the two dual ESCs that I have, and in both cases, as long as the PWM is plugged into the master ESC (the one CAN forwarding the throttle to the other), then the “Remote Y” value in the app read correctly. Is this how you have it setup with the ubox?
I was also unable to recreate the crashing issue on either of the android devices I have. To debug the app crashing and pwm control issues, can you tell me what android version you are running and what ubox version you have?
This is likely a bug introduced in later FW / App updates that never got caught. I believe you are the first user to actually really dig into the custom mode, so there haven’t been any eyes on it till now lol
If I recall correctly, the biggest issue was finding a good way to implement the individual LED strip on/off functionality while maintaining the generic structure that I setup for the digital modes. It has been a while since I worked on that portion of the FW so I cant remember the exact details. But it certainly is possible to implement, just with some restructuring.
Do the strips light up very dim when this happens? It is possible that the UART tx/rx signals of the uSplit are back feeding into the TTL, but it wouldnt make sense for the strips to light up.
A momentary push button wired like in the image below can work to control the lights. That is, however, if your “remote configuration” settings are set to PWM and Momentary. Really the biggest issue faced here is the app crashing since that prevents alot of debugging and experimentation with the settings. So I hope to fix that first.
Ok so with the Ubox you have to input the pwm signal into the secondary esc for the break light to output correctly when it is used with a pwm remote so this may be the issue. It is the same esc that the ttl is plugged into though so maybe not. I have to test again as I’ve had to change remotes while I repair my damaged puck - ill send it through its paces once I have it back on the bench and consistent access to an android device.
I have been borrowing an android phone to do the calibration and testing so i don’t have that info but the ubox i have is the .9 hardware (silkscreened on the pcb low voltage side) and firmware 5.2 on the UBOX V2 75v 100a dual vesc
HA! That’s funny because the first thing I do with everything i get is mess with the custom settings and generally take it apart to see how it works. I end up buying two of things often because they are designed to hinder or outright punish people for opening the case. “Warranty void if removed” is more of a challenge than a warning to me lol. Also illegal to enforce if it is a US company even if it is only in principle as the laws are being defanged
It was quite bright but I couldn’t really manipulate the ttl to get the output to go 100% (x acceleration mode) as everything was just connected in order test before closing up my enclosure.
I tried using the fob relay in this configuration for the control of the ttl. Thanks for confirming the wiring- I thought i was taking crazy pills.
but I wonder if I wasn’t successful because it was being back feed or held in an on state because of the uart fsr. Ill be getting an android device in the next week and we can revisit this whole thing then.
Just to make you laugh: when I isolated the on state issue to the uart connection i had a brilliant plan - just use it in its current state and unconnected to the vesc for now toggling the power on and off to control it and not using the vesc feedback. Ez right? So i slap it all back together without the uart cable and close up the 134 enclosure screws and power the board and ttl back on… i had to change the orientation of the ttl in the enclosure and I only had access to an android device for another 15min. Reload the app and try to connect… no bluetooth signal. Opened it back up, uart back connected, confirmed i now see ttl bluetooth, close it back up, calibrate and set mode, reopen board, remove uart, re confirm everything turns on, close up enclosure, test… no leds. Forgot to connect them when I flipped the enclosure the last time after testing because i was rushing lol. Opened it all again and connected. Im going to have to make a quick connection type of cam bolt or something or some m going to wear out my imbedds
@Ricco think I figured it out but maybe you can confirm something for me: does the ttl use a common ground breaking the positive? This is what it looks like to me but you would know best lol. As soon as I isolated the ubox outputs from the ttl outputs 100% it started acting right. The ubox outputs all break the negative and use a common positive control setup.
Unfortunately that makes the more complicated interaction of the ttl and ubox lighting I planned too complicated to pursue but i have the ttl working like a champ now. Still having some issues with the app but nothing that can’t be worked out.
I wish the ubox outputs were just dry relays, i could do so much more with them. Or if they had made them common negative. Seems like they don’t know that as I asked them about this when i got some lights from them for testing and they said that they used negative common to be compatible with off the shelf 3 wire car and motorcycle lights and sell three wire lights… ¯_(ツ)_/¯
Your build looks sweet! Way to go getting arou d the issues you have been having with the TTL system! It looks like you solved the PWM throttle reading issue, and the remote not working.
The UPS actually breaks both the positive and the negative of the TTL power because all ESC implement their integrated power switch slightly different. Some of them disconnect the high side and some disconnect the low side. In your case, since the Ubox disconnects the GND, then maybe the high side of the UPS is damaged and stays connected. That would explain the TTL lights turning on due to the UART connection.
Very interesting and good to know! I havent heard that before.
Ive dont this dance so many times! I think if I did another build I would want to try using push button hood latch pins. Those would make enclosure removal super easy
After about 6 years of working on the TelTail Lighting System, I have finally decided that the project has come to a conclusion for me. As promised in past discussions with various community members, now that I no longer have time to progress the project any further, I have released it as open source so that anyone who wants to continue where I left off, or just build the system for themselves.
Here are links to each of the Github repos created for this project:
I will certainly continue to provide customer support for anyone with the TTL system, and will gladly help anyone that decides to build off of my work. I just will not be restocking any of the TTL components on my webstore and will not be pursuing the implementation of any new features in the hardware or software.
I have learned a lot from this project and plan to carry that knowledge forward into new endeavors / creations. Thank you to everyone who has supported the project over the years and encouraged me to bring the TelTail Lighting System to life.
Ive dont this dance so many times! I think if I did another build I would want to try using push button hood latch pins. Those would make enclosure removal super easy 