Skip to content

Add TVGAIN support and fine-tune the gain/threshold values#390

Open
FabianSchwartau wants to merge 2 commits intoopenbikesensor:mainfrom
FabianSchwartau:fix_us_overload
Open

Add TVGAIN support and fine-tune the gain/threshold values#390
FabianSchwartau wants to merge 2 commits intoopenbikesensor:mainfrom
FabianSchwartau:fix_us_overload

Conversation

@FabianSchwartau
Copy link
Contributor

@FabianSchwartau FabianSchwartau commented Mar 3, 2026

Hi everyone,
we had two of the five OBSPro prototype sensors that did not work properly. The sensors always showed a reading fairly close to the sensor. I am not 100% sure of the cause, because I was not able to reproduce it (probably due to temperature differences). However, I am confident that this was caused by too high reflections and/or ringing of the transformers/transducers. The PGA460 sensor chip allows to set a bunch of parameters, thresholds, and time-varying gains to fine-tune the behaviour of the transducers/transformers used. This patch introduces the use of the time-varying gain (TVGAIN) to suppress the first strong reflection and increase the gain for targets further away. I also fine-tuned the threshold values and timings accordingly. This optimization process may take a few more iterations until we arrive at an optimal setting for the hardware and its variations.
Maybe we want to provide this patch to some of the current testers and see if it works on multiple units, before we merge it.
I also wrote a small python script to debug the ultrasonic sensors. Where can I put this? A "tools" subfolder in this repo? Is there a better repo? Maybe https://github.com/openbikesensor/OpenBikeSensor-Scripts? A new repo?
grafik

@gluap
Copy link
Contributor

gluap commented Mar 3, 2026

From my perspective a "tools" folder would be fine.

I could imagine it might make things easier to set the threshold very high for times corresponding to distances that are below the handlebar width - as these are not actually sensible candidates for a measurement.

Wouldn't make this obsolete for cases where the sensor is mounted at the left boundary of a bicycle as some cargobike users do, but would open opportunities of not accidentally measuring legs, bike bags etc... on bikes where it is mounted center.

@gluap
Copy link
Contributor

gluap commented Mar 3, 2026

Applied the new version to the "Wander-OBS". Observations:

  • low distances (below 30ish cm raw value) do not measure reliably, sometimes nothing is measured, sometimes some higher value is displayed (even when there is nothing in that distance even on the other side of the sensor or e.g. when the other side is the open sky).
  • Values above 30ish cm seem to be reliable up to >400cm (against cars) or up to 550cm (against walls).

From my perspective this is fine. Below 30cm is typically below handlebar width, so these values shouldn't matter anyhow. even people with 40cm handlebars typically are wider themselves than 40cm, so anything below 30cm with a centered OBS is unlikely to represent an overtaking event.

@gluap
Copy link
Contributor

gluap commented Mar 3, 2026

I alerted the other two testers -e.g. @tobst

@FabianSchwartau
Copy link
Contributor Author

I had another look at targets below 30cm. Yes, this is a problem. But I do not think we can do much about that. This is the dead-zone of the sensor. I might be able to reduce this down to 25cm (maybe 20cm if I push it hard), but this may reduce the reliability. False positive measurements in this range may rise. I would suggest we leave it as it is right now and see if this is good enough. Is this much better with the classic sensors?

@FabianSchwartau
Copy link
Contributor Author

I have also added the small python debug script.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants