Just gotta type in Vesc dude. https://play.google.com/store/apps/details?id=vedder.vesctool&hl=en
1 Like
Fair enough. We could talk about android then. AFAIK its open source and every manufacturer tweaks and customises their own phones. So lets just take Samsung and rooting their phones. I am pretty sure if you did a warranty claim with Samsung because an update bricked your phone and they found out that your phone has been rooted, I am pretty sure they would reject it.
2 Likes
Im sure they would, as would I if I were Samsung. But noone is rooting their VESC, they are applying upgrades, that by any reasonable assumption, should work. You can take the analog too far.
Letâs make it simple. One of 2 things happened hereâŚ
- The app & firmware release happened WITH the knowledge that it would brick non-VESC ⢠hardware and Trampa/Ben didnât care.
- The app & firmware release happened WITHOUT the knowledge that it would brick non-VESC ⢠hardware because Trampa/Ben didnât do sufficient testing.
Either one of those scenarios lays a substantial part of the blame on Trampa/Ben.
2 Likes
I will take responsibility. I am very sorry for what happened to you @NullReference and I will try to make sure this doesnât happen again. I am already working on it, I will disable new untested firmware versions by default and put enable button deep into Developer options with some explanations. Donât sell your board for partsđ
19 Likes
I have calmed down a bit since yesterday. I donât regret anything I said yesterday. However, I probably wonât sell my board.
5 Likes
Thx for your statement and apologizing for the mishap. I hope you will be able to integrate new FW support soon. Itâs quite some work, but should be doable. If strict FW version crosschecks are from now on implemented, people shouldnât be able to brick anything. I hope that other App developers followed the conversation and act accordingly to avoid user frustration over bricked HW.
1 Like
I donât think so, but maybe that would help others to get an idea about compatibility. In the end you always need to test things to work 100% before publishing new App versions. I will dig into that and ask about the idea behind VESC FW versioning.
1 Like
All software engineers should be using semantic versioning, including Vedder and third party addon developers, because it will allow for these software checks that you are pushing for to actually function properly. â
A.B.C
This means as long as A doesnât change, itâs considered backwards-compatible. Any change breaking backwards-compatibility has to increment A and reset B and C.
Incrementing B is for feature additions, and should reset C
Incrementing C is for bugfixes
So for example, a version â17.4.2â would be compatible with a future version â17.5.1â but not a â18.1.1â
11 Likes
Yep, thatâs what weâve been saying
1 Like
What ESC are you using? My FSESC 6.6 works with their Bluetooth module.
Edit: the flipsky Bluetooth uses 51822 module.
2 Likes
You will need a NRF 51822 module with VESC firmware on. Go to our homepage and type NRF into the search barâŚ
The HM 10 is to slow for real time data and firmware updates. It would also not allow simultaneous connection to a remote controller and phone. The NRF module will be your remote receiver in future.
@mmaner STOP TROLLING and get positive.
6 Likes
This still needs to be proven.
I like the redundancy that 2 separate receivers offers, with both ESCs connected only by the power supply, and you seem to be moving in the direction of
ah rip, too many modules to keep track of, thanks
@deltazeta, What do you mean âripâ?
BTW, you can also get the nrf51822 module from adafruit: https://www.adafruit.com/product/4076(<$13 shipped) and burn it with a hex file located here: https://github.com/vedderb/nrf51_vesc, provided you have a stlink v2 programmer.
1 Like
The idea is to have one module only, handling all tasks. This module is ideally a NRF 51288.
@b264, we donât experience and esc dropouts. Non of our boards ever had such an issue. Iâm not sure if you can pair two NRF modules simultaneously to one remote for redundancy reasons but Iâll find that out.
The downside of PPM receivers is that you donât know what happens when the receiver has an issue. It could go into a mode sending throttle/brake commands although you donât want that. The ESC canât know that something is funny with the receiver and would take the command. Having two receivers you double the chance for such failures.
NRF receivers do not have this issue. They canât send an unwanted command. Either they work, or not. If they drop out, your board is free coasting or goes into a pre-defined brake mode. The past has shown that NRF 51 based modules work very vert reliable and interference doesnât really exist.
Thing is: ESCs should be max reliable and simply work. In our experience with the VESC 6, spontaneous ESC dropouts do not occur. However, I can understand that redundant designs are always preferred.
1 Like
You can, but you have 2X shipping (ST-Link and Module) plus flashing the NRF is not as straight forward as flashing a VESC. On Linux systems it is more simple, windows more complicated. If you have the knowledge and patience you can use module xyz. Past has shown: Some modules work better than others, and some are troublesome. I would say that its hardly worth the effort to make one yourself. Might save you 10 bucks that you spend on soldering and time later.
Iâm not only talking about lost signal situations. What if brine has ingressed the enclosure and shorts out an ESC?
There are so many things that could go wrong, and I think that Benjamin is doing lots of good things. But you assuming that we will only be using that a certain way with everything interconnected is perhaps not realistic, and while it might work for a toy, there are more preferred ways for tools that must be relied upon.