Jump to content

Bill N

Members
  • Content Count

    48
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Bill N

  1. Also, it might be worth noting that if people just set their cruise control at a given speed (eg 60 mph), then the actual speed they are travelling at could vary by a few mph depending on the car model due to different levels of speedometer accuracy between manufacturers. So it might be worth advising people doing the manual test procedure to set their cruise speed based off a GPS speedometer (eg Waze) in order to eliminate that variance.
  2. Jason - if following the manual test procedure, wouldn’t it also be useful to report the weather conditions at the time the test was conducted? Also, could you perhaps outline which car models you don’t really need any manually collected data for - i.e., because you’ve already got sufficient data and/or there are enough people providing automated live data? For example, would it still be beneficial to provide manually collected i3 data even though automated live data collection is now possible? Thanks
  3. Oh I think I see what you mean now. If ABRP knows I am driving from A to B, and that I need to stop once to charge, it should already be including the time it takes to cover the distance from the highway to the charger. If my understanding is correct, you shouldn’t include the time it takes to drive from the highway to the charger in the overhead. The overhead ought to be pretty similar for most charging locations (although less for Tesla Superchargers where you literally just park and plug in, and maybe a little more if you know you are going to use a charger where you can’t use an RFID card and have to fiddle with a mobile app). As I understand it, ABRP will pick a charger that is less travel time from the highway (whilst also giving weight to other factors, such as number of stalls, network preferences etc). What I think you are suggesting is that the time taken to cover the distance from the highway to the charger may, in reality, be longer than is estimated at certain locations. For example, if: - the location data of the charger is not quite accurate and the charger is in fact at the far side of a large and busy car park. - or, the location data is accurate, but the car park where the charger is located is often busy with cars manoeuvring, pedestrians etc meaning that it take several minutes more to get to the charger than the navigation routing anticipates. In theory, I guess it should be possible for ABRP, when used with a car with a live car connection that reads the SOC, to know when the car has actually started charging and so to calculate the average time elapsed between cars leaving the highway and starting to charge at that location. It could also differentiate between different times of day, as at some locations the overhead may be significantly different at certain times of day. On the face of it though, it feels to me like this would be quite a lot of work to implement, and possibly for only marginal benefit - but maybe not!
  4. My understanding of overhead is thats it’s purely the (average) time taken between stopping driving and charging starting - usually a function mostly of how quickly the driver is able to park, get out, find the correct RFID / app, plug the cable in and then get the charger to activate. It’s normally about 2-3 minutes, in my experience. The extra travel time taken between coming off the most direct route to the destination and driving to a particular charger should already be accounted for. The main scenario I can envisage where the plan allows for only a few minutes but you ending up taking significantly more is if you get stuck in a queue waiting for a charger to become available.
  5. I would like this too please. I'd like to be able to prevent a route entering Sweden (also due to Covid-19 travel restrictions).
  6. Bill N

    My feedback...

    Yep, lagginess could in part be due to me being on an iPhone 7+ that also could probably do with a factory reset - although other apps are performing okay, and ABRP Classic is snappy and smooth. I am going to get around to a factory reset and fresh install and see if that improves it. I like the idea of 'simple' and 'advanced' settings, and think this could be used to allow for more 'involved' users to tinker with more settings, whilst other users don’t need to bother. I still think it’s probably a little way until the type of people a) driving EVs and b) knowing about using ABRP are not in the main quite nerdy and not put off by 'advanced’ settings. I can however see why ABRP is aiming to make using the software more simple and hands-off, and the time will come when EVs start reaching mass adoption and mostly 'normal' (!) people drive them, and ABRP will maybe by then be baked into cars. The idea about limiting charging stops to location with more that x stalls could be another thing that is 'hidden' in advanced settings, so most users don’t mess with it and then end up with “no route found”.
  7. Bill N

    My feedback...

    #22 When the settings screen is set to simple mode, and user taps on departure SOC to change the value, the settings page doesn’t always slide up so then the keyboard ends up blocking the user from seeing what is being typed. Sometimes it is okay, but more often than not it isn’t.
  8. Bill N

    My feedback...

    A new one... #21 - the time entry in waypoint setting for departure time is clunky - requires user to type a colon and it isn’t possible to scroll down the list of suggested times. i would suggest (if possible) to only display a numeric keyboard and eliminate the need for a colon to be typed - so the user can just quickly tap in 4 digits to get any specific time and the colon is added automatically by the set formatting.
  9. Bill N

    My feedback...

    On #10 at least - my bad - I was unwittingly using a web bookmark on my home screen rather than the actual iPhone app. Using the app, scrolling the saved plans screen does work (albeit not particularly smoothly).
  10. Bill N

    My feedback...

    Thanks for the quick and comprehensive response Jason! 1 . Yes, I've just checked and I'm still getting this on the latest version on iPhone. For example, I have a number of different cars saved, and if I switch to one and then switch back to my actual car (i3) the reference consumption jumps about to a seemingly random figure (ie. not 3.8 like it should be for the i3, but also not the figure that it was on for the other car I had momentarily switched - very odd). 4. Maybe there's another way to do it from a UI perspective rather than a pop up - maybe the calculate route button could show the start SOC that the planner is going to use, and if you need to change it you could touch and hold - then it brings up a numeric only keyboard so you can really quickly and easily (and safely) enter the actual SOC that you are starting with. At the moment, you have to go into full settings or origin waypoint setting, tap on the current SOC setting, delete the current figures, then type in the new figures on a Qwerty keyboard, then tap done, then calculate. As an aside - it would be good if all fields throughout the app where only numbers need to be entered could bring up a numeric keyboard instead of the Qwerty keyboard. 7. It does seem as though no confirmation is needed - but maybe there is something in the UI that can be improved so that the user gets some sort of confirmation that the change has been made - eg a display saying something like "Your estimated SOC at [name of destination] is now x%" 10. In the iPhone app - I have just double checked and it definitely won't scroll. I can only move the slide-up page up and down the screen, or tap into one of the saved plans, but I can't scroll down (or up) the list. So I have one saved plan at the bottom of the page where the name is cut in half. I think it's connected with the #6 problem - so probably iPhone specific. 11. I emailed about this separately before and Bo had suggested maybe an (advanced) option for the user to optionally say how important the preference for locations with more stalls should be. The problem is, here in the UK at least, many locations still only have a single stall and they often just can't be relied on if you wan't a stress-free trip. So, as it is, I find myself using ABRP in a clunky manner, manually checking the number of stalls at each location and then adding the preferred chargers as waypoints. Just on #3 - I agree this should definitely be the focus at the moment - I tried the classic version the other day and since then I've found myself going back to it quite often because it's just so snappy in comparison - but, alas, you then can't take advantage of the life traffic & weather features.
  11. Bill N

    My feedback...

    Hi, I’ve emailed this in, but thought I would post here too so that others can also see my feedback and maybe add their thoughts / comments... Hello ABRP team, I'd like to give you some feedback ... 1. There seems to be a problem when switching between different vehicles - the reference consumption doesn’t always change accordingly. 2. Please add a feature like Glympse to enable live trip sharing to allow friends/family to follow progress including charging stops. (Glympse doesn’t really work because the ETA doesn’t account for charging stops). 3. Scrolling in the settings is laggy and not “iOS smooth“ 4. Please make the start SOC setting front and centre. For people who are using ABRP without a live SOC reading from the car, they need to check and enter the start SOC for every journey. Please make this setting pop up every time you press the calculate route button if you don’t have a live connection to the car set up. 5. Add other favourite address settings in addition to or instead of “work”. Lots of retired people with EVs don’t got to “work” but do make regular trips to another location. 6. The bottom bar containing the calculate route button often seems to float up on iPhone and then gets in the way - must be a bug. 7. Please clarify how adjusting the actual SOC during a journey works? In ABRP classic I had to adjust it and then tap to confirm, and then it would adjust the estimated SOC at destination. How does it worknow? Also, there is a long lag when tapping the up / down arrows to change the actual SOC. 8. Notifications don’t appear to work at all. 9. Please allow for different speed settings for highways. For example, I stick to speed limits in urban areas so use 100% in settings, but then I travel over the speed limit on quiet highways. The settings don’t allow for this. 10. Scrolling on the ‘saved plans’ pop up screen doesn’t work at all so I can’t see half of my saved plans. 11. Please allow a setting to try and route only using charger locations with a minimum of 2+ stalls. 12. Please add a button on iPhone to quckly select car / configuration - there is one on Android but not iPhone. 13. Add force touch shortcuts on iPhone for favourite destinations - also widgets in ios14. 14. Enable deletion of recent destinations 15. Show live GPS speed on map. 16. You could also include other features like speeding alerts - see Amigo app for example. 17. The UI when you tap on an address field box in the planner is confusing - it takes you to the screen with home and work and recent destinations but it’s then not obvious how to go to back to the previous screen. 18. The settings for “fast chargers” and “avoid on route” would be better as just simple switches like the other settings, instead of pop-ups. That would also make it quicker to see what is currently set to on, and would make it easier to hopefully avoid tolls and/or highways and/or ferries instead of having to choose just one. 19. Include a list of all individual charger locations that have previously been set to “avoid this charger”. 20. When tapping alternative route button include some basic info on what the alternative routes are - eg the main road that it takes - the same way that most other sat navs would.
  12. Description: live trip sharing, like Glympse Use Case: I like to use Glympse to let people know when to expect my arrival. The problem with Glympse is that it doesn’t know I’m going to stop for 25 minutes to charge on route. Please implement a feature to allow simple live trip sharing so that I can email or text a link to people, they open the link, and can then follow my love progress (including charging stops). Ideally, you’d have similar features and options to Glympse (eg current speed on or off, favourite contacts etc) Thanks
  13. Yes, in the UK we can either use Maingau to pay about £0.4 per kWh, or ChargePoint to pay £7.60 per session.... so it would be good for ABRP to always show the required kWh, even if it does know the price the network itself charges (£0.69 per kWh for Ionity). That way we could easily work out whether we should use Maingau (<19kWh) or ChargePoint (>19kWh).
  14. Adding my voice to this request - but I’d prefer it to always show how many kWh need to be added. Would be useful when deciding which method of payment to use at Ionity chargers, for example.
  15. Hi, There's something I'm confused about... When planning journeys, I often add waypoints to the journey plan just to force a particular route to be followed. I don't intend to stop at those waypoints, but simply drive past them so that I drive the route I want to and avoid certain roads etc. As far as I can tell, ABRP will show me the estimated 'arrival charge' but this is always the charge at the next waypoint (regardless of whether I intend to stop there or not). The problem is that I don't care what the SOC will be at the waypoint that I am just going to drive straight past... I would much rather see what the SOC is estimated to be at the next charging stop, or at the next actual destination. I think ABRP could be improved by allowing the user to select whether a waypoint should be treated as an interim destination or simply as a routing waypoint. If the user tells ABRP it is an interim destination, then ABRP will show the estimated arrival charge at that point. If the user tells ABRP it is just a routing waypoint, then ABRP won't show the estimated arrival charge at that point, and will instead use the final destination / next charging stop / next interim destination. Or, maybe I am doing something wrong when using ABRP in the car??
  16. Does anyone else have this problem? Or am I doing something wrong?
  17. Description: When driving, I would like to be able to see the live estimate of the arrival charge at the final destination and/or the next planned charging stop even when waypoints are added to a journey. Use Case: When planning journeys, I often add waypoints just to force a particular route to be followed. I don't intend to stop at those waypoints, but simply drive past them so that I drive the route I want to. As far as I can tell, ABRP shows me the estimated arrival charger but this is always the charge at the next waypoint (regardless of whether I intend to stop there or not). I don't care what the SOC will be at the waypoint which I will just drive straight past.. I would much rather see what the SOC is estimated to be at the next charging stop, or the next actual destination. I think you could improve this by allowing the user to select whether a waypoint should be treated as an interim destination or simply as a routing waypoint. If the user tells ABRP it is an interim destination, then ABRP will show the estimated arrival charge at that point. If the user tells ABRP it is just a routing waypoint, then ABRP won't show the estimated arrival charge at that point, and will instead use the final destination / next charging stop / next interim destination. Thanks
  18. Yes, it's almost impossible to model that I would have thought - as it depends largely on the precise density and proximity of traffic at any moment in time. I was just really trying to think of other possible explanations for the discrepancy. Live data driving would certainly help significantly once you are on the move, but I'm not sure if it would help so much when it comes to pre-planning a journey out of the car. Unless, maybe, ABRP used the journey data collected from cars, in conjunction with available wind data for the time and location of each journey, which you could then apply to the raw car data to refine the model - so the next time a user enters a forecast wind speed of X, when pre-planning a journey that involves driving at Y degrees relative to the forecast wind direction, the model knows to increase the energy consumption by Z (adjusted for ground speed). I think the trouble is, there are so many localised factors that could potentially affect the actual wind that is affecting a car on a given road. So windy.com, or the nearest weather station, or whatever might say that the current wind is blowing SSW at 10mph, but the actual wind hitting the car might only be 7mph and might be blowing SW, due to local terrain, road side trees, binding, embankments, vehicles on the opposite etc etc. But, over time, and with more and more data points, it might be possible to define a good enough 'wind adjustment factor' for each car.
  19. Thanks Jason. Yeah, I do check the wind direction pre-departure via windy.com, and also use teslawinds.com whilst on route. If the wind direction would not result in either a direct headwind or tailwind, what I've done is just try to guesstimate a lower wind speed and entered that into ABRP - which still seems to result in a greater predicted impact than what actually materializes. It’s tricky though because (here in the UK especially) a route rarely follows a straight line - so you have to try and take into account the wind direction and then the variations in the direction of travel along the length of the route. In theory, (though I appreciate it’s probably far from straightforward) it should be possible for ABRP to pull the forecast or current wind speed and direction data and apply that to the model whilst factoring in the car speed and direction at different points along the length of the route. The other potential factor I’ve pondered is that whilst driving along a fairly busy 3 lane highway with other vehicles positioned to 3 (or sometimes all 4) sides of your own car, the actual airspeed of your car is possibly reduced and is not simply ground speed +/- wind speed because the air immediately surrounding your car is, to some extent, being ‘pulled along’ by the constant flow of moving objects.
  20. Bill N

    IOS & Android App ?

    I would pay for an app.
  21. Yes, IME, the i3 (sadly, just the i3 not the i3S here!) model is good, if quite conservative. I think the reference ‘consumption’ for the plain i3 120Ah can safely be increased to 3.9 mi/kWh, at least. IME, the only time the predicted SoC is significantly different to the actual SoC is when I enter a headwind in the settings. I check windy.com to see the wind along the route I am planning, and use that figure (or a little less) in ABRP - but, IME the impact of the predicted SOC is always greater than it actually needs to be. I don’t know whether this is because: a) The ABRP model is over-playing the impact of a headwind on the energy consumption. or b) The actual wind affecting the car is not as significant as that stated by windy.com. or, a combination of both. As it is though, the wind setting is essentially not much use because the predicted impact of wind is not borne out by reality.
  22. This is all kinda not that intuitive - perhaps a bit of a basic user guide would be good?
  23. The quickest plan for that journey (2h30m) is to limit the max speed to 130km/h so that you don’t need to stop to charge. That’s an average speed of 97km/h (based on a 241km route). That compares with your suggested 110km/h average in a polluting diesel car, which would save you 17m30s (12% quicker), but cost substantially more in fuel and pollute the areas through which you drive. Budget permitting, you don’t need to wait for a bigger battery - just a get a Model 3 LR instead of a SR+.
  24. If it was point A to B and then point B to point A via the same route then my understanding is the wind (and elevation profile) would *mostly* cancel each other out; however, my understanding is the benefit gained from a tailwind (and/or a down hill) is not necessarily equal to the losses incurred due to a headwind (and/or an up hill). Also, when I started this thread, I had in mind a route that went from point A and back to point A, bit via points B, C, D etc... i.e a ‘circular’ round-trip, rather than a bi-directional, linear ‘round-trip’. In the case of a circular round-trip, the winds may be completely different for different sections of the route, and even if they weren’t and the route was a perfect circle, I’m not sure the impact of the wind would be negated.
  25. This You Tuber has some videos on Leaf 40 battery temps etc which my be of some help:

Contact Us

Bo - Lead Developer and Tesla owner: bo@abetterrouteplanner.com

Jason - New Car Models, Developer and Bolt owner : jason@abetterrouteplanner.com

Idreams - Forums Administrator, Forums Developer and Tesla owner : idreams@abetterrouteplanner.com

×
×
  • Create New...