yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] rigattoni:
Hi [MENTION=4292729]SpeedFire-[/MENTION],

I did not update yet, but I stumbled over:

<<SNIP>> Now when the speedlimit data is received the app also records a rectangular related to this speedlimit. While the car is within the bounds of this zone no further requests are made (this will save mobile data as well). <<SNAP>>

May be I´m wrong and you considered it in your implementation, but what´s about zone:maxspeed=DE:30, which is really critical at least in Germany? To record a rectangle should work in most cases, but I think it needs some attention because these zones are really often places to have speed cameras.
[Android Head-Units] SpeedFire-:
Rectangle is set by OSM for the zone where this speed limit is valid. When you go outside this zone FCC will send a request for new speed limit.

P.S. To exclude situations when you turn to the other street within some large rectangle - new speed limit request is also sent when the street name is changing.
[Android Head-Units] tjaller:
Do i need premium to make my steering wheel controls work in Spotify?

It works when changing radio station, but doesn't skip song in spotify, even though i selected spotify in the settings.

I don't know if it's related, but i cant see the steering wheel keypress in steering wheel study program either.

Also... when i look at the sticker on my unit with the wiring color codes, i have one blue wire which is not documented on that label, and it goes from the HU to the CANBUS decoder thing from bagoo.
[Android Head-Units] SpeedFire-:
It doesn't depend on premium. Probably your type of commands from steering wheel is just doesn't recognized.
[Android Head-Units] tjaller:
How come they work in the Radio app then? Sorry if this is not related to FCC Car Launcher, but i have asked all over and i get no response at all.
[Android Head-Units] SpeedFire-:
They work via your head unit's MCU. FCC is not involved here.
[Android Head-Units] tjaller:
So changing MCU version to another manufacturer will give a different result
[Android Head-Units] SpeedFire-:
I can't comment on that. This may or may not work. Anyway this is a dangerous operation as far as I know.

In the future I will try to add recognition of buttons via canbus, but first I need to understand how to connect some universal hardware buttons to my device.

Can anyone help with that? (I don't have any connectors for my device so I'll need to purchase them as well on eBay / AliExpress / Amazon. Link is appreciated)

My PX5 device:
[Android Head-Units] tjaller:
Well.. My theory is that the cambus adapter emulates keypresses from a keyboard.

Is seems like it it\s either page up/down or arrow up/down or scroll up/down when i use the wheel on my steering wheel control.
[Android Head-Units] oscyp:
you need to use key1 and/or key2 wires

analog universal hardware-buttons are shorting the circuit with a different resistance (depending on which button is pressed) and those wires from HU can recognize it

I was able to connect an old wheel-buttons on my colleague's car successfully that way.

It is not dangerous - just be sure you don't short anything you wouldn't like to :)
[Android Head-Units] tjaller:
Well i already tried something similar. But the output from my canbus decoder doesn't give me different voltage outputs fro button to button. I'm thinking it's a digital signal, rather than a difference in voltage.

There is absolutely no documentation on the canbus adapter at all. tried googleing it and nothing shows.
[Android Head-Units] oscyp:
Voltage won't be changed.

Resistance between the output wire from the buttons and ground will be different.

And key1/key2 (I don't remember which one) can recognize those changes.

And if this is a digital signal from canbus - then MCU should serve this.
[Android Head-Units] Scopesys:
Do you have any steering wheel controls connected to the Key 1 Key2 Gnd (and possibly +acc for power) ... and if so, does FCC recognize their Key Codes when trying to define custom key actions within FCC.

If not ..

https://www.ebay.com/itm/Universal-Wireless-Car-Steering-Wheel-Control-Remote-Button-For-Stereo-DVD-GPS/122845192367

I will gladly donate the above if it helps.

Note sure about the Connector that may needed needed for your HU.

What is your HU. Typically, they come with the connectors with wires attached, that plug into the HU, with bare wire ends on the other end of the cable for you to make connections to.

However, the Key 1 key2 are on the main POWER/SPEAKER connector, which I assume you have, to be able to power up your HU. (which is a pretty Universal Connector for most HUs)
[Android Head-Units] sbruda:
If by changing the MCU you mean changing the MCU firmware then there are good and bad news. The good news is that yes, you will obtain a different result. The bad news is that the different result is the unit being bricked. The MCU firmware is always specific to the manufacturer of the particular MCU you have.

For the SWC buttons issue, if they work with the radio then they work correctly as far as the MCU and OS are concerned. I am guessing that you have just not chosen the right action for those buttons so you may want to play with the settings. Note that there are several kinds of advancing actions (next track vs. fast forward, etc.; on my units they appear as various pictograms in the respective settings panel), it might be that Spotify expects a different such an action compared to the radio.

For example you may have the forward/back buttons bound to fast forward and rewind, which accomplish tune up and tune down on the radio alright, but don't do squat on say, Poweramp which expects next/previous track events (which in turn will do different things on the radio such as scan right and left). If this is the case then you have no good solution (you just need to decide which actions are best for you).

I hope I am not too far off and that it helps. In any event, from what you are describing the problem is not at the MCU/OS level. It might be caused by the button assignment (as exemplified above) or by Spotify integration issues (of which I know nothing).

---------- Post added at 12:26 PM ---------- Previous post was at 12:13 PM ----------

That's right, both Key1 and Key2 expect a resistive ladder (you get two for the event that a car has two such ladders). In CAN bus based cars the CAN bus adapter should receive the digital events and convert them to one analog output (resistive ladder-like). In other words Key1 (and possibly Key2 though this is rare) should be connected to the CAN bus adapter. At least this is how all the HUs I have ever seen worked...
[Android Head-Units] SpeedFire-:
Yes, I have this major connector so no problem should be here.

Regarding remote. I try to find this / similar remote in some local store. I go on vacation in a week, therefore I can't order now items from eBay etc (they will arrive when I'm not at home). If I find it I will try to briefly test it before my vacation.
[Android Head-Units] oscyp:
Mystery resolved then :)

So no matter if you have can bus or not - you should just connect the output wire (from the hard-buttons) to the key1 or key2 in HU - that's it.
[Android Head-Units] Ben.suffolk:
So just to clarify how this work for people. Older Steering Wheel Controls have a number if buttons connected to a resistor network. Pressing a button changes the resistance present. Some cars have a single wire, some more.

Some head units have just single Key wire, some have 2 (Key1 & Key2). In all cases the measurements is between a key wire (1 or 2) and ground. The head units with 2 wires allow you to connect 2 different sets of buttons (Some cars have buttons on both sides of the wheel and are connected to 2 different resistor nets).

If you car has just 1 wire, the resistance will be between that wire and ground already. So just go ahead and connect it to Key1 and your done.

If you have 2 wires, chances are they are either side of the resistor net (you can put a multi meter across it to check). In this is the case connect one of the wires to Key1 and the other to ground. Job done. This is the most common setup. Its also the one you would use with a set of universal buttons from eBay.

If on the other hand you have 2 wires and 2 sets of buttons, then connect a wire to Key1, and one to Key2. If you have 2 sets of buttons and 4 wires (or maybe 3) you will need to connect 1 to key1, another to key2 and the 3rd and or 4th to ground. You will need a meter to check which ones are which probably.

This does not apply to cars with can bus buttons.
[Android Head-Units] SpeedFire-:
Finally! Smooth camera rotation on MiniMap in the next release:
[Android Head-Units] rigattoni:
[MENTION=4292729]SpeedFire-[/MENTION]

I found some strange behavior in startup.

The screen keeps black for ~10 sec.

I will take the radio out on the weekend to refine some parts from the sofa, instead of sitting in the car for hours. Will come back to this issue when I sorted some other things out, which could be the reason...
[Android Head-Units] SpeedFire-:
It is true. Startup time is too long now.

I started to investigate this issue yesterday. No quick results so far. I will continue. This is an important issue.

How is the overall performance when everything is loaded?
[Android Head-Units] Scopesys:
Talking about "taking time" reminds me:-

When doing a backup, after it starts, the starting indication vanishes and thereafter there is no indication that the backup is taking place, until later, another message pops up saying backup completed.

If you are not aware of this, you could easily start doing something while the unit is backup up, thinking that the backup had completed, and potentially corrupt the backup.

Suggest an indication is kept informing the user that the backup is taking place, until it is finished actually doing the backup, and then informs you that backup is complete.

Don't recall how will it keeps the user informed during restore, but the same should apply for restore.

I would assume that doing a RESET while it is restoring may potentially really screw up the database ?
[Android Head-Units] cyverboy2:
Updated to latest release on beta channel in play store, and minimap is a mess now :(

1. Current position arrow is completely missing

2. Minimap is struggling all the time. It looks like the Position is updating only every 1 second :(
[Android Head-Units] SpeedFire-:
Try to restart your device once
[Android Head-Units] sbruda:
I concur. I am experiencing the same problems I had in the earlier version, only more severe. This applies to the mini-map and also the street name widget, the speedometer, and probably the speed limit widget. In fact it would appear that the sluggish update happens now right off the bat, even after reboot. :(
[Android Head-Units] SpeedFire-:
Hmm. What device and os do you have? Can you record another LogCat?
[Android Head-Units] sbruda:
KLD MTCD PX5 with 4GB of RAM running Malaysk's Marshmallow ROM version 7.0.

Sure, will do as soon as I find the time.
[Android Head-Units] SpeedFire-:
Thank you!

I really need a LogCat log. Maybe it will give a clue on what is happening. Because last version runs smoothly on both my test PX5 device and emulators.
[Android Head-Units] cyverboy2:
Restarted several times, no improvement :( It's a xtrons PX5!
[Android Head-Units] rigattoni:
[MENTION=4292729]SpeedFire-[/MENTION]

I don´t use the mini map, but I use the speed widget. Since last 2 updates in beta channel the speed often shows 0 or - for a second.

So I think that the mini map issues some user claimed is related to the GPS data forwarding to FCC.

Might not happen with recorded GPS data and with mocked locations, just happens with real GPS data, because the feeding data out of a file seems to be handled different as real data from the GPS receiver. May be you try to observe the frequency of GPS data inflow in FCC.
[Android Head-Units] Scopesys:
[MENTION=1633144]speedfire[/MENTION]

Ref: Speed Limit Widget

I have been using this Widget (Really like it), and been having my passengers carefully monitor it as we travel, and move between different speed limit areas ( USA).

(1) Sometimes, while we are clearly still traveling on the same road, with the same speed limit, the Widget turns blank (no speed limit).

(2) Also, it was mentioned in an earlier post, that the Speed Data format varies from country to county, and that FCC way not be aware of every format (but that is being worked on :) ).

So, to help figure out what is going on, can I make the following suggestion.

Add the "Option" to the Speed Limit widget to display 2 Text Fields.

(a) The Speed RAW Limit info as supplied by whatever means is getting the data, and that FCC is using to calculate & display an actual Numeric Speed Limit display.

(b) A counter that counts in seconds, since the last speed limit update, of that above Raw value. (Maybe like 0 - 99999).

This will enable users to get an insight as to what is really going on, and be able to report back if they see any non-FCC included speed codes appear in their country, that cause an incorrect Speed Limit Display, and give that precise information feedback to SpeedFire.

--------------

Can I assume that if I am traveling a GPS calculated route, say here in the USA, and at some point along that route, find a stretch of the road where the Speed Limit display appears to be incorrect, that in theory, it should be possible use that route later to simulate that journey, at a simulated speed, and feed simulated positions to the Google API (or whatever is returning the speed limit data), and effectively simulate that previous trip, and hopefully see what went on as far as the speed limit data collected ??

If the unexpected return of Speed Data and the resulting display cannot be resolved, this might be a good test tool to evaluate what is going on, at any time and from any location, (ie driving along a given road in the USA, while developing FCC in Russia), and in a controlled, repeatable test environment.

An important question is ... Is it incorrect data being fed to FCC, or is it FCC not optimally processing correct data. The above might help to get this resolved in a thorough and timely manner., both now, and at any time in the future, should there be further issues with Speed Limit processing.
[Android Head-Units] SpeedFire-:
Recording your route is a good point. That will be useful. Record it in gpx format please (apps should be available in Play store).
[Android Head-Units] Scopesys:
Ref: Player Widget.

In FCC, I have setup a Music Player page, where I can select from a number of Music sources (ie Poweramp, Amazon Music, Google Music, Pandora, the Car's FM/AM radio), and expect to see that selected, currently running player, displaying in the Music Player Widget, with album art (or Radio Station Arts if available by FCC), Song Title, Artist etc, and have the ability (If the given player supports it) to Jump to next track, jump back from the steering wheel controls, and display progress (once again, if the current player has progress - which for instance, the car's AM/FM radio obvious does not) etc

This works reasonably well to some extent, but it often inconsistently not functioning correctly, in different ways, at different times.

The selection of the player is always working, and whichever player is last selected, is the player that runs, and audio from previous players is stopped correctly. (even if a previous player is still loaded )

Generally, forward and reverse works, and the correct notification appears, with the new Song and artist etc.

But very often, the Artwork and the Artist/title in the widget never updates, and continues to display the old artist/title, and even sometimes the old info from the previous player.

Also, often the progress bar does not display the correct info, very often, just contining to increment from the position it was in in the last player, when it was working.

ie Does not get initialized to the current position in the current playing song.

It is not easy to see a pattern as to when this incorrect behavior occurs.. restarting FCC typically makes it initially work better, but over a short time of changing players, it get more and more broken.

This being said, with the above issues, one can happily play music, and select different players, and those players run fine, and if one enters the player, all the correct artwork, artist, song, progress is there, -- its just when returning to the FCC menu, and looking at the Player Widget on that FCC Menu screen, while a given player is playing, that the widget information is not correctly updating.

Does not make FCC unusable, just frustrating to use, as the FCC player widget is not displaying the correct, current information from the currently running player.

So, maybe for the time being, this can be noted as an issue, and addressed sometime when time and priorities allows.

---------- Post added at 06:52 AM ---------- Previous post was at 06:41 AM ----------

Will do -- I know a specific length of road near my home where I have seen this issue occur. I will get the recording app installed, run the route a number of times over the next few days, see if it consistently has the same issues, and get the gpx files to you, :)

---------- Post added at 07:01 AM ---------- Previous post was at 06:52 AM ----------

[MENTION=1633144]speedfire[/MENTION]

Just occurred to me... would it help if I sent you a copy of a backup of my FCC configuration... then hopefully you could see this happening with the same FCC configuration and menu setup that I am using. ?

J
[Android Head-Units] rigattoni:
[MENTION=4292729]SpeedFire-[/MENTION]

I went back to the official build because the beta is too faulty in the moment... but I know tht this can happen with a beta version, so all fine in the moment. I will switch back to beta if it is at least starting up as the official one.

But let me point on wrong behavior which should be fixed:

<Preconditions:>

Create a Tasker task

<Action:>

Issue 1:

Go to home screen

Long press on the screen

Choose Widgets

Move down to Tasker

Choose

Task

Pull Icon to the edit button

Issue 2:

Go to home screen

Long press on the screen

Choose Widgets

Move down to Tasker

Choose

Task shortcut

Pull icon to the edit button

<Observed:>

Issue 1:

+ Icon is drawn on the screen

- There are no settings as for apps available

- There is no text displayed

- The button is not like the app buttons on the screen.

Issue 2:

+ Icon is drawn on the screen

+ Menu for customizing the logo and label pops up

+ A logo can be added

+ A label can be added

+ After press OK a message pops up the restart FCC.

- Whether the icon nor the label are overtaken.

<Expected:>

A way to add Tasker tasks in the same way as for apps, because they work like an app.
[Android Head-Units] sbruda:
Location woes again (with logcats) + app drawer

Today I tried again to help in identifying the issue with FCC reading GPS information. Recall that this is all happening on a MTCD KLD PX5 with 4 GB of RAM and running version 7.0 of Malaysk's Marshmallow port.

First, I should mention again that everything is smooth on a cold boot. The speedometer widget, the current street name widget, as well as the mini-map all update smoothly. Here is a logcat that was taken at the point at which the head unit was suspended. My untrained eye did not see anything out of ordinary in this log.

Now here is a logcat that includes information about the events happening after resuming. My (let's not forget, untrained) eye has noticed the "java.io.IOException: grpc failed" error that keeps appearing in the logs and seems to be produced by a sub-system related to the functionality that is experiencing problems. In any event, here is what happens after resume:

The speedometer widget shows the current speed intermittently. At other times it believes that the vehicle is stationary (displaying a dash). In fact most of the time it shows a dash and only occasionally decides to show the actual speed. The current street name and the mini-map both update now and then. They appear to never update while the speedometer is showing a stationary vehicle, but even when the speedometer shows an actual speed they still may not update. On my way back (after resuming the head unit) the street name and mini-map updated once (when I got out of a parking lot and onto a street) and then they sat frozen for the whole trip. During the trip I let FCC update, but that did not solve the problem; the mini-map and street name remained frozen.

The latest two versions made the problem worse. In a previous version the mini-map and street names were updating in jerks but at least they updated; now there are many instances in which the mini-map and street name are frozen. Frustratingly, in a much older version (though I am not sure which one) the mini-map and its siblings worked quite well.

Could you please look into this issue. While this behaviour is not a show-stopper, it is annoying and should be fixed. Many thanks!

Oh, and since I am at it, I noticed that the search bar in the app drawer is gone (thank you!), but now the first row of apps overlap with the status bar (they are displayed as if the status bar is not present that is, as if the app is full-screen). Could you please also look into this one? Thanks again.
[Android Head-Units] SpeedFire-:
New beta 3.077 is sent:

- Fix of hiding All Apps after sleep

- Other fixes

Please check
[Android Head-Units] Julian75ts:
Is It available in PlayStore or other link?
[Android Head-Units] SpeedFire-:
Available now in Play Store on beta channel
[Android Head-Units] Roerbakeitje:
[MENTION=1633144]speedfire[/MENTION]

Your app is not in the Playstore anymore
[Android Head-Units] SpeedFire-:
Are you sure? I don't see any issues: https://play.google.com/store/apps/details?id=ru.speedfire.flycontrolcenter

Here is direct link to the latest release: FCC Launcher 3.077
[Android Head-Units] Roerbakeitje:
Thanks i made. Screenshot of Playstore . Did you make IT mabe not avaleble for all country
[Android Head-Units] SpeedFire-:
Try to search as "FCC Car Launcher". Maybe Google just put it down the list due to not very high rating.
[Android Head-Units] Roerbakeitje:
That whas the trick thanks
[Android Head-Units] Scopesys:
[MENTION=1633144]speedfire[/MENTION]

When going to download/install betas, I cannot see any indication of what version is currently the offered/latest, BEFORE I download and install.

Could I suggest you put a little more information onto the Play Store beta downloading page, so we can see what we are committing to before we download and install.

Instead of just

- Fix of hiding All Apps after sleep

- Other fixes​

add the beta version #, and also a change log of the say last 5 betas.

ie

Beta Version 3.077

Fix of hiding All Apps after sleep

- Other fixes

Beta Version 3.076

Fix of ??????????

- Other fixes

Beta Version 3.075 (Unstable)

Fix of ??????

- Other fixes

Beta Version 3.074

Fix of ??? widget

- Other fixes

Beta Version 3.073

Fix of Map

- Other fixes​

I would assume you only would have to enter the bet beta version and it's changes at the top, and delete the last on to keep the list a reasonable length.

BTW: It would be nice to be able to see a complete change log for all beta version, at least since the last major release.

If a complete change log was maintained, then the Download page could just maybe contain the Cut-Pasted last (say 5) part of that full Change Log and a link to the full Change Log