• Content count

  • Joined

  • Last visited

  • Days Won


esaj last won the day on May 25

esaj had the most liked content!

Community Reputation

4,256 Excellent

About esaj

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

4,729 profile views
  1. Not sure how much weight my opinions should be given, considering that my only real technical expertise is in the software-world, not mechanical engineering or electronics
  2. Yeah, it's just a flu and mild fever, but I'm taking it easy and not riding until it has passed. Just blowing my nose every 10 minutes Took the day off today.
  3. Well, if LinkedIn numbers can be trusted (probably not? ), Gotway is marked in the 11-50 employees bracket ( ), whereas King Song Electric Unicycles is in the 201-500 employees bracket ( ) . But like said, those might not be actual numbers. I'm not saying King Song is "better", they just seem to have taken a different, more conservative approach. Over-engineer and use components with higher ratings than seems necessary. Limit the maximum speed and power outputs so things don't fall apart. Gotway seems to push the envelope in the opposite direction, "how much speed & power can we get out of these things" I'm happy with lower speeds (technically, anything above 1000W nominal and/or 25km/h max speed is illegal here, otherwise EUCs are legal) and (maybe ) higher reliability, but for people who want speed and power, the Gotways (and Rockwheel GT16's, with some reservations as it's too new to really know much about) are the way to go.
  4. This may not be the case (although it could be). A quick decompilation of the app shows that the value is being read as 16-bit integer, no Math.abs() or such: this.current = (byteArrayInt2(paramArrayOfByte[10], paramArrayOfByte[11]) / 100.0F); BUT, the devil is in the details: private int byteArrayInt2(byte paramByte1, byte paramByte2) { return (paramByte1 & 0xFF) + (paramByte2 & 0xFF) * 256; } Seems harmless, right? And Java uses signed values, so it would seem the value is sent as positive... Except, in this case, the binary operators come into play. ANDing with 0xFF actually promotes the paramByteX to an int, then strips off everything except the lowest 8 bits. Since it's a full 32-bit int, the sign-bit is in the MSB, which is always 0 in this case, meaning that any sign in the original value is lost. Whether this is actually meant to be, I don't know, it could still be that the board always sends the value as positive. Maybe this will be clearer to understand what I mean: private static int byteArrayInt2(byte paramByte1, byte paramByte2) { return (paramByte1 & 0xFF) + (paramByte2 & 0xFF) * 256; } public static void main(String[] args) { int val = byteArrayInt2((byte)1, (byte)0); System.out.println("0x0001 = " + val); val = byteArrayInt2((byte)0, (byte)-1); System.out.println("0xFF00 = " + val); val = byteArrayInt2((byte)127, (byte)127); System.out.println("0x7F7F = " + val); val = byteArrayInt2((byte)-1, (byte)127); System.out.println("0x7FFF = " + val); val = byteArrayInt2((byte)-128, (byte)-128); System.out.println("0x8080 = " + val); } OUTPUT: 0x0001 = 1 0xFF00 = 65280 0x7F7F = 32639 0x7FFF = 32767 0x8080 = 32896 The point is, with the way byteArrayInt2 is written, it will never return negative values, even if the original data was meant as such (signed value, MSB as sign bit). Whether the value is capped elsewhere in the app (the actual current is the value divided by 100.0f, so if there's a sign-bit, and it's capped at 70A, it will always show the maximum value if the sign-bit is set, or whenever the final value is more than 7000), I didn't check. It might still also actually be that the mainboard doesn't send signed values, and instead sends 7000 (divided by 100.0f, that makes it 70). I'd need to take a data capture from actual braking situation to see the original data. Wheellog has probably just copied the value calculation straight from the King Song app, so it behaves the same.
  5. Foxconn and iPhone are good examples, but I'd wager that most of all electronics is made in China today, from mobile phones to computers to high-end professional equipment (many oscilloscopes are made in China or Malaysia for example, still cost thousands). I guess it's down to the company making the orders to keep the quality in check. But yes, Chinese are very capable of not only making, but also designing world class machines. But the higher quality is probably not as cheap If you have a population of 1.3 billion, there's bound to be pretty smart people in there too. I guess it mostly comes down to tightening the QA. Gotway apparently isn't a really big company, so likely they try to make do with minimal design staff and without much overlap. Smaller details like the wire gauge (design problem) and soldering have issues (QA problem). They might work just fine with a light weight rider in level ground, yet totally die with higher weight or more extreme conditions. Hard to say if it's just cost cutting or simply plain oversight though. Solowheel's are made in China too, "Designed in the USA/Assembled in China". But they slapped a $2000+ -price tag on the Xtreme, so probably it doesn't sell that much. I think the typical problem with the wheels is trying to push too much power and speed and leaving too little safety margin. Solowheel Xtreme has 1800W motor (don't know if it's nominal or maximum though), yet the rated max speed is 16km/h. One of the biggest reasons I picked King Song was that they at least seem to have higher quality in general, and don't try to squeeze out too much of speed. KS16S uses a 1200W motor, with max speed rated as 35km/h, and yet uses the highest rated mosfets I've seen so far (Over 2 times smaller Rds(on) than the ones on Gotways/GT16, also the cost is about 2-2.5 times higher per piece), although Chris from 1RadWerkstatt may have had his part in pushing that change through . KS16B had 800W, and 30km/h rated, don't know on the mosfets. But yeah, they've still had issues like the weak pedals on some batches about a year ago. But in general, their process seems more streamlined and advanced, it probably helps to have the machinery to make your own boards for example (" Prior to self balancing scooters business, King song has been engaged in developing and producing power bank protection board, all of the control boards of king song scooters are made by our own SMT factory, which is one of our advantage compared to our competitors, we can be more flexible and gurrantee quality of core components.") :
  6. The spot-welder's waiting for more parts, as I found out through simulations that the stray/parasitic inductance in the cables can cause the voltage to spike above 100V and destroy the mosfet-switch bank with high currents. It will take a while, as I try to order components in bigger bulks to save on shipping, so I try to collect a larger list of stuff I need before ordering. Now that I have wheel(s), I haven't spent much time on electronics, but I got some fever and haven't been able to ride today or yesterday. Today I thought I'd try my hand at creating a combined speedo/odo/tripmeter and battery voltage meter. The first prototype doesn't have its own step-down to power from the wheel batteries directly, but instead simply relies on "something" else giving it 5V supply voltage. Nothing really special there. The 5V supply voltage comes from some outside source through a connector, and is put behind a (smallish, couple of hundred milliamps?) PTC-fuse, some bypass caps (for this prototype, I'll use just some MLCCs, I think I have those up to 47uF range) and a "jumper" (maybe I'll use a switch instead) to turn on and off the thing. An Arduino Nano will work as the brains of the device. Rest is just the 7-segment drivers (MAX7219's), bunch of connectors, pull-up for a hall-sensor to read the speed from tire rotation and a voltage divider for finding out battery voltage. Trip will be calculated based on speed, and total mileage will be intermittently saved into EEPROM, say every 200 meters for example, to save on the EEPROM write-cycles, and every time the wheel stops for longer than some amount of seconds (5 might be a good value). To save on the EEPROM wearout, it could also be interleaved by writing into consecutive addresses and at startup, reading through them and picking the largest value. Tire circumference will be hardcoded for prototyping. I was thinking of using an OLED-display to show the values, but the ones I have are really small (about 1" from corner to opposite corner), so they'd be hard to read if showing many values (small characters), or it would have to alternate between different values, which would mean I'd have to stare down at it for longer when I want to see something specific. Instead, I decided to go with 7-segment leds, actually four of 4-character displays, driven by two MAX7219's. I did a similar setup last summer on a breadboard: The working principle is pretty basic, measuring time passing between ticks got from a hall-sensor, and calculating the speed from there knowing the tire diameter and amount of magnets (how much distance it has traveled over time). I planned on using 6 magnets (I think I counted that the KS16 motor sideplate has 12 bolts, so it's easy to place them equally by placing one next to every second bolt). MAX7219's are pretty easy to use and each can handle up to 8 characters (so one 7219 for two 4-character displays). By using four displays, it's easy to show speed, trip and total mileage, plus battery voltage at the last one. For voltage measurement, I made a simple voltage divider with four 2.2k -resistors in series (to help with the power dissipation in each resistor) and 620ohm at the low-side of the divider, giving a ratio of 620 / (4 * 2200 + 620) = 0.0658174097664543524416135881104. For 67.2V (normal battery maximum), this will give 4,4229...V. I left some headroom vs 5V, as braking can momentarily push the voltage higher than battery maximum. At 5V reference, the LSB step of the 10-bit ADC will be around 4.88mV, which for now is enough precision (it's a little less than 75mV in the real battery voltage). It could be taken further with things like using more precise resistors, dropping the voltage lower and using a precision reference for the ADC, and/or using a separate 12- or 14-bit ADC chip, maybe I'll look into those in the future if it seems necessary. Likely the voltage's going to be jumping up and down a lot anyway, plus there's going to be all sorts of noise there anyway. There's also a small capacitor (marked as 1n at least for now,) to smooth out sudden transients and a 5.1V zener to protect against overvoltage, but might have to lose the zener if it looks like it has too much influence on the readings (it has both capacitance and leakage). The impedance of the divider is relatively low (< 10K), as the cap has leakage, and apparently this can cause lots of error in the readings when using high impedance divider. Plus the MCU datasheets suggest using less than 10K input impedance for it anyway. It will draw about 6...8 milliamps, depending on the battery voltage, but considering how big the wheel batteries are, it's peanuts, especially compared to the mainboard and the motor draw. To prevent it from wasting charge when not in use, probably a switch should be added, but a better option would probably be using a logic level N-channel mosfet against the ground after the divider, that will be turned on only when the meter itself is powered. Assuming I ever get around to make a "better" version powered directly from the wheel, it will likely have an off-switch, or detect whether the mainboard's turned on, so it shouldn't discharge the batteries on it's own. There's some extra connectors so I can easily add more devices using 5V and get access to the digital pins and the I2C-pins if need be. The 30k resistors for the current limiting of the 7219's are just a "rule of thumb" (should be around 20mA for red 7-segments), might need to tweak those around, if it seems that the segments are too bright (is that even possible? ) or if it draws so much current that it will eat away at it's own battery too fast. I haven't cut the board yet, as it got pretty late before I had the layout down, I first tried with DIP-packaged MAX's, but ran out of space fast on a single-sided board, but fortunately I had some in SOP-24 (SMD) -packages too. The MAX's could be chained together through the DOUT/DIN -pins, but the traces would have to jump through some hoops, and I had pins available, so I decided I'd control them separately from the MCU. Still had to add some 0-resistors to keep the ground-plane intact and a jumper (the via in the layout) to transfer +5V to the hall-sensor -connector. Trying to get the board milled during tomorrow... I can run the CNC while I work, so shouldn't be a problem, unless I can't get clean cuts at those SMD-chips. I set the feed rates so low that it shouldn't be a problem, but you never know
  7. Yes, that's the one I use... It's a (relatively) cheap helmet I bought from Biltema (a Swedish store-chain): Unfortunately no pages in English, they've got stores only across the Nordic countries (Sweden/Norway/Finland/Denmark). The sun-visor thingy's quite useless, but otherwise it's pretty good.
  8. AFAIK, at least King Songs use 6 mosfets, looks like that for the GT16 also. Could be just cost saving and keeping the board complexity down... The mosfets are the same as in the newer Gotways (IRFP4110), not exactly high-end but apparently good enough without paralleling (at least until someone weighing 100+kg tries it? ). The large casing (TO-247) also helps with heat dissipation vs. the "usual" TO-220's. It's the black part the board sits on. More pictures here: EDIT: Picture of an unpainted heatsink:
  9. I don't think it matters which way around the motors are installed (as long as the phase wires are connected correctly). Likely for the motor, there is no "forward or backward", at least from the winding and electronics point of view... And even if it did run in the opposite direction (probably achievable if the phase order is changed to "correctly" reversed), wouldn't that mean that when you lean forwards, the motors would run backwards and faceplant you? At least most if not all wheels (as in electric unicycles) run similarly no matter which way you turn it, in the early days, people were actually confused which way around some of the wheel should be ridden There's of course a rotation direction marked in the tires, but that usually has to do with the pattern in the tire, when running in "correct" direction, the patterning throws water away from the middle towards the sides to prevent hydroplaning (but with the speeds and area touching the ground these things got, I doubt it's easy to hydroplane even if running it "backwards"), and some wheel casings are built so that there's a distinctive forward and backward-side, but they still could be ridden "the wrong way around".
  10. Testing the different ride-modes of the KS16, I noticed that (for me) it's easier to accelerate/climb up hills with the softer modes vs. the stiffest "Player mode". I'm not sure why that is, but I suspect it has to do with the larger "dead zone" around the 0-degree position and allowing the pedals to tilt forward a bit when leaning into it, so it could be that in the stiffest mode, and especially on stronger wheels (power vs. rider weight), it's harder to get enough lean forward when climbing hills for the firmware to react strongly enough. But it's just a theory. Could you try some time if a softer mode helps in hill-climbing with the Monster? I don't even know if it has different ride-modes, though...
  11. For future reference, the 3-pin connector is called MT60:
  12. Not at least yet, she isn't totally opposed against trying to learn, but doesn't seem too excited about the idea either We'll see, I'm not riding right now either, as I got some fever... I already had a runny nose and sore throat sometime in the week, but it seemed to pass. Guess I tempted fate too much with my long friday-night ride in cold weather (+5-6C / around 41F), and now pay for it
  13. Might be, on the wheels I've had, the BMSs (apparently) only balance at full voltage (4.2V per cell). The first couple of hours of charging might get something like 2-300Wh (for example) into the batteries, but for the voltage to go all the way to around 67.2V and the charge current to go really low (tens of milliamps), it might still take 3-4 hours after that (on a 16S4P / 14Ah total packs), and those last hours only charge a few tens of Wh into the batteries, because the current is so low. The Firewheel-charger I had already changed the light to green when the charging current dropped below 250mA, but it would still take something like a couple of hours to really top up/balance the pack.
  14. Have you measured the charger output voltage to be the full 67.2V? At least on my wheels, the battery voltage drops a bit (but not that much) after removing the charger, even if doing a full balance charging until about 50mA current running into the packs. The voltages will also drop a bit under load, so might not show full 67.xx if there's any load on them, like when the wheel's turned on. If you're worried about it, might be worth checking the battery voltages themselves, with the wheel turned off so there's no load, the wheel voltage measurements may not always be 100% accurate. If the BMS in the Lhotz can do active balancing (not only when charged to full), the difference isn't really big though (4.2V per cell vs. 4.08V per cell), somehow I doubt that last about 0.1V gives that much more, and charging to a slightly lower voltage should just give more useable cycles to the batteries. The voltage drops from 4.2V to around 4.0xx ... 4.1V pretty much immediately (a few mAh spent) at 2A, faster and to lower voltage with higher currents. Although the mainboard won't draw 2A and the motor uses very little current idling, it could still be due to the cells being under load?
  15. I'm no expert, but I suspect without modifying the firmware, the only option would be to use larger tires. You do get a tradeoff between speed vs. torque though. AFAIK, there is no separate measurement for the RPMs, but it's all tied to running the motor. At low speeds, the wheels seem to use the hall-sensors. If you go mucking about with their placement or such, the software cannot run the motor correctly, and cannot balance. At higher speeds, it seems that the wheels start to use a "sensorless mode" to estimate the position and the speed of the motor, that's built into the software itself. It could use something like back-EMF -voltage or current flow for input information, but again, if you go mess around with the measurements (like by changing the shunt measurement resistors, unless they're actually using current sensors), the end result is likely that the software cannot drive the motor correctly. And if they're not using sensorless detection, then they're likely still relying on the hall-sensors at higher speeds too. Someone like @electric_vehicle_lover can probably shed more light into the issue, or maybe even knows a way around, these are just my personal conclusions based on (the little) that I know.