@Fosterqc I do have a binary dump of the latest official SB FW, but I don’t know enough about disassembly to know how to start decoding the FW to see what is being done for traction control.
I’ve made a bit more progress in getting the mainline VESC FW ported. There were a bunch of pins that SB re-map’d relative to a VESC6.6, so I’ve slowly been ohm’ing through the board to figure out what goes where.
I think I know what was causing my front wheel not to spin, the motor temp was reading back as 300C for the front motor and like -200C for the rear motor. There’s actually no motor thermistor wire going through the castors so I hard coded the temp function to a fixed 30C.
My bench power supply tops out at 25V @ 1A and that doesn’t seem to be enough to run dual motor detection wizard. I’ll have to switch to LiPos once I do a bit more pin scrubbing.
On the topic of traction control there is an ICM-20948 IMU connected to ARM B that drives the back wheel, which I did get working. The remote nRF receiver is tied to ARM A that drives the front wheel. There are no Hall effect sensors and I’m not sure if VESC FW can determine the wheel RPM with only back EMF, at least it’s not obvious to me from the real-time panel that the FW knows how fast each wheel is spinning.
Maybe someone that understands esk8 physics better can comment, but I could see that the IMU could determine which motor is leading and which is lagging and under the assumption that the rider has their weight distributed more towards the back it slightly boosts that motor to compensate for the additional weight?
Do traditional esk8s typically have an IMU? If so what does it do?
I think board speed is normally calculated with the wheel RPM (Hall effect) and a known wheel diameter right?
Oh interesting, so those other “mosfets” are actually diodes on the phases (ST PS30H). Never seen that before
I don’t have the ESC in front of me at the moment, but I’m pretty sure those are MOSFETs and the DRV8301 is used in the normal way. If I’m wrong I’ll report back.
Then this piece goes in the box and we bolt all the way through to the deck. However seems like when I originally did this I didn’t put the inserts in straight looool. 3 bolts it is. It will be fiiiiine.
It can. It only uses halls for very low rpms when there isn’t enough back emf to measure. Silent HFI works pretty well on some ESCs and can be a replacement for halls at low RPMs
You can see the erpms in the realtime tab of the vesc tool
As far as I know the traction control (at least on the Leif that came before) detected when there was caster rotation and limited the power available when a rotation was initiated. At least that’s how I remember the board behaving with traction control on. I remember it feeling weird and turning it off even when I was a very beginner as it was so odd feeling.
@jaykup Thanks I missed that there is an ERPM tab in RealTime section, I confirmed this also reads back values on the sensor-less SBX ESC. I also realized that mainline VESC has traction control which appears to read in ERPM values for all the motors and limits any motors spinning faster to the slowest motor. I’m not sure if that’s something that would help or hurt a e-freeboard.
I also finally got mainline VESC FW working, although not extensively tested.
I even got the SB remote working. It turns out SB uses the vanilla nRF24 driver with the one exception that they’re running at a quarter of the baud rate and decreased the retry rate, presumably to improve the radio link? So actually you should be able to use any nRF24 based remote with the SBX ESC.
For some reason enabling the IMU prevents the back motor from spinning, but as far as I know the IMU isn’t used for anything, except for OneWheels applications, so I’ve just commented it out.
There was well known interference and other issues with the early sb remote connection. if you search their FB group you might find some dead links to said update files.
I mention this in case if seems something is tweaked in an odd way regarding that.
Interestingly I couldn’t find any discussions on VESC-Project or on this forum about recommending to change the nRF24 data rate to mitigate interference.
The nRF24L01 data sheet Table 7 shows a typical 9dB sensitivity and 5dB blocking improvement performance when using 250kbps vs 1Mbps; trading off latency/responsiveness.
So it would make sense that Summerboard would go down this route and do a software update to the ESC & Remote if people were reporting interference issues in the field. Putting a battery over the receiver probably doesn’t do the radio any favors.
Looking at the VESC code, it looks like the nRF24 is fixed at 2476MHz as opposed to Trampa Wand/Hoyt Puck which are frequency hopping and inherently more robust.
The nRF24 wasn’t used very long with vesc. They went to nRF51/52 almost right away.
One of the more reliable remotes out there, the z.mote, uses nRF24. Maybe the creator @zyb can provide some insight as to how his remote firmware is configured to get the signal quality so good
He seems to dislike TI BMS controller chips…a standard for millions of packs.
He said they’re “going back to basics…”, so that means the low cost China controllers? Or the dirt cheap China single channel circuit (available everywhere on the web) just paralleled as needed for the pack?
Hi, I’m going the DIY route for my e-freebord project with a Stormcore 60D and a 12s2p. It’s my first build, I’m not on a budget. Was the whole setup to heavy with the stormcore and 12s3p? Or do you have other insights to share why you have changed the ESC and batteries?
The reason to not use a stormcore is it can max at 18S where these motors would explode stuff at that voltage, so might as well use the reasonable 12S esc like a Xenith/makerxdualwhatever
