Some recommended tips for maintaining your electric skateboard battery

  • The first thing you need to do after buying a brand new electric skateboard is to charge the battery. The battery is an important part that directly affects the range your board can ride, so you need to take care of it closely. Here are some tips & tricks to help you keep the battery in top condition and help it last the longest.

    How long can your e-board last?

    First, you need to know the range and the lifespan of the electric skateboard battery. This information is explicitly provided by the seller. It may also be printed in the manual or on the product's packaging. On average, a standard e-board can travel 8 - 20 miles, and have 300-1000 charge cycles. If you use the board daily for travel, the battery can live 1-3 years. There are many factors that affect the life of the battery, the most important of which is the type and the quality of the battery. By improving the factors beyond these two, you can extend the battery life to 2-3 years.


    Tips to maintain your e-skateboard battery.

    Here are the do's and don'ts that I've compiled based on my experience using 7 motorized skateboards.

    Things recommended to do

    If you notice that the range is different the first few times, this is normal because the controller is calibrating the fuel gauge. What you need to do is just ride normally and don't worry too much. Things will get better in the next few rides.

    You should fully charge the battery before first use. Maintain full charge and fully discharge the board for the first 5 cycles. This helps speed up the calibration process and you'll quickly achieve the full range.

    After the first 5 cycles, remember to always charge your battery after each use regardless of whether the battery is fully or partially used.

    If your battery is very dirty and you need to clean it, use a damp cloth to wipe it. If you wash with water, the electronic parts will be easily damaged and stop working.

    You should unplug the charger when the battery is full. In case the battery has a BMS (Battery Management System) system, you can leave the battery in the charger. This even increases the lifetime of your pack. Not only does this do no harm, but it also increases the lifetime of your pack.

    The battery connectors are made of metal, so they are easy to rust. Make sure you check it often enough to detect and deal with damage promptly.

    Thing you should avoid doing

    You should not remove the connector from the battery. This is an important part. Even if you promise to put it back the way it was, are you sure you installed it correctly?

    Avoid exposing the battery to water or submerging the board in water even if the manufacturer says the board is water-resistant. The battery will die if it is immersed in water. I know many of you like riding through deep puddles after rain. Well, stop that idea if you don't want your board to not be able to wake up the next day.

    Never uncover the connector when riding your board. The connector is attached to the bottom of the skateboard, bringing it closer to the ground. If you expose the connector, dust will get into it easily and shortcut the battery.

    Never let your battery disconnect when riding. This will cause the battery to overcharge if your board uses the regenerative braking system.

    Avoid overheating your battery. The battery is sensitive to high temperatures, it may explode or catch fire when exposed to fire or left in a high-temperature condition.

    Avoid opening the battery without the guidance of an experienced person.

    Never puncture your battery

    In case you have problems with your board, you should not fix it yourself without much experience with electronics or you will end up with a messed board.

    I see many websites about electric skateboards that mention this issue, especially eSkateBuddy. This Blog has some solutions to help you solve common problems in e-skateboard as well as many other great tips. If you have time then don't forget to check out this website right away. It will not disappoint you.

    Bottom line

    The battery is almost the most important part of the skateboard. If you take care of it with all your heart, it will take care of you in return. When there are efforts made from your side, the board will surely remain your experience as fun as it is supposed to be!

    • This topic was modified 3 months, 1 week ago by  jarenadams.
  • There's little you can do from SQL Server itself. However, one thing I do know about is that the ring buffer does collect connectivity issues. I show how to use Extended Events to capture that information here. Yeah, that's for a third party monitoring tool. But that doesn't matter. It's the Extended Event session that will give you timeout reasons.

    ----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • Personally, since you are getting RDP disconnects, I would be bringing that up to the network team and reviewing the windows logs during that period.  That will likely tell you what happened as to why the connection dropped.

    As for what can cause it, we had a similar issue recently where some internally hosted web services were unreachable.  First investigation was to confirm that if it was a problem for the WFH people as well as on and off VPN or if it was just on-premise.  The network team saw one switch with high traffic and eventually narrowed it down to an individual workstation.  That workstation was using up a LOT of bandwidth and causing overall network issues to anything connected to the same switch.

    What I would confirm is if the server you were RDP'ed into was on the same switch as the databases and the connection timeouts.  In our case, pings were not a good troubleshooting tool as 32 bytes of data (the normal for a ping) went out and came back successfully, so we knew the server was online and responding to pings.  Your network team MAY have disabled ping responses so you may get timeouts no matter if the network is fine or busy.

    There are free monitoring tools that can help with monitoring bandwidth such as Cacti, but they are very trivial in what they monitor and in our case, was giving false positives that the databases were eating all the bandwidth.  I ruled this out quickly though.

    My opinion - rather than trying to prove there is a network issue, tell the network team the symptoms and the timeframe of the problem and have them come up with the root cause and solution.  It MAY be that they were reconfiguring the firewall and it caused something to reboot that caused the network interruption and booted everyone off of that server (RDP and SQL).  I have worked in IT and if people come to me claiming that there is a problem with XYZ and everything is working fine for me right now, I get frustrated with the ticket and will indicate that I can find no fault.  BUT if they come to me saying "server ABC booted me off at approximately 10:07 AM today.  Reconnect was successful after 5 minutes, but then it booted me off again at 11:07 AM.  Can this be investigated?" I would have looked into it and came back with a solution.  Someone says "your system is broken" and my tools say "everything is running fine", I'm going to report back that things are fine UNLESS I am given more information about what to investigate.  Server Name, Timeframe, and users impacted are critical parts to investigating suspected network issues.  It MAY have been someone updated the NIC drivers on the VM or VM host and it caused a minor network interruption.  It could be the VM crashed and started itself back up within a short timeframe so it seemed like a network issue (VM's can boot up very quick).  It could be the VM had a snapshot or backup running on it that ran long and caused what appeared to be a network hiccup.

    I would NOT immediately blame the network for the problem.  I would report to the server team that there was an interruption in service at approximately time xx:yy that appears to have affected server ABC and impacted tools XYZ.  Can this be investigated.  The server team can then review the logs to see what happened and they may determine it was network related.  The windows logs (if you know where to look and what to look for) can show network related errors.  If it is a repeated problem, reporting the times it happens is helpful too.  For example, if it happens on the hour or VERY close there to or daily or weekly or any noticeable pattern, it could be a scheduled task of some sort using all the resources (CPU, memory, or bandwidth) allocated to the server and it needs to be bumped up.

    TL;DR - I wouldn't immediately blame the network.  I would reach out to the server team to investigate the issue and let them reach out to the network team if they determine it is network related.  And I would report the symptoms, not the "guess" as to the problem (ie network) as you may be reporting the issue to the wrong team (network team when the problem may be VM related for example).  Let the server team investigate the logs and let the server team reach out to the appropriate other teams if necessary.  Report the RDP disconnect and timeouts, and include server name and time problem occurred, and if applicable, include if the problem seems to follow a pattern (daily, hourly, weekly, etc.).

    The above is all just my opinion on what you should do. 
    As with all advice you find on a random internet forum - you shouldn't blindly follow it.  Always test on a test server to see if there is negative side effects before making changes to live!
    I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

  • This was removed by the editor as SPAM

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply