Jump to content

Bill N

Members
  • Content Count

    48
  • Joined

  • Last visited

  • Days Won

    3

Bill N last won the day on July 20

Bill N had the most liked content!

Community Reputation

7 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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??

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...