Opened 13 years ago

Closed 11 years ago

#2527 closed defect (wontfix)

Turtleart sensors buggy on XO1.5

Reported by: tonyforster Owned by: walter
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Turtleart Version: Unspecified
Severity: Unspecified Keywords:
Cc: Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

There are at least two buggy states. Measuring voltage on a capacitor should give 1.69V bias at equilibrium, one state is 1.72V, the other is a noisy 1.5V. When buggy the audio modes are affected too.

In the first state, sound =-1000

In the second state noise appears on Volume and Pitch too.

Clicking stop (so far) clears the buggy state.

Get a buggy state one in 3 cold boots, once working the buggy state is less likely to appear till reboot, maybe not at all.

The first time bias is set in a new instance of ta it produces a type cast error, but only once (may not be relevant).

Change History (8)

comment:1 Changed 13 years ago by tonyforster

can clear bug with

save_state()
resume_state()

triggering it manually from the kb

but putting it in set_sensor_type (of audiograb_XO15 class) before _set_sensor_type doesnt

comment:2 Changed 13 years ago by walter

Going in and out of the program (to get to the keyboard) causes some change in state for audiograb as well... could be the combination of all of the above.

I'll try to take a look as soon as I get home and have access to a GNU/Linux environment.

comment:3 Changed 13 years ago by tonyforster

I did check for this, using keyboard event in tawindow.py I can trigger a function in audiograb.py (audiograb_XO15 class), if that subroutine is just a print it has no effect but if it has save_state() resume_state() it clears the bug.

From this I deduce that this code clears the bug if executed at the right time.

The right time is not either immediately before or after _set_sensor_type

comment:4 Changed 12 years ago by tonyforster

Testing whether the calibration is now more reliable:
All units XO-1.5 OS880 Sugar 0.94, measuring 22k+680 resistor on L channel, R channel o/c
red/purple and green/purple are TA V114 SKU104
Tony1.5 is TA V130 (as at yesterday) SKU99

All units failed to initialise sometimes on first run after boot, they measured an erratic high value. They all then measured OK pressing stop then start (except once*)
Failure rate to initialise after boot was:
green purple 4/8
red purple 3/8
tony1.5 2/8

Conclusion: TA V130 can only be at most marginally better

  • had a fail mode that I have not noticed before, (for these tests its 1 in 48 trials). It measured OK after boot but after stop/start it measured a low 2k value, this fault did not clear for subsequent stop/starts. It is likely that the bias did not turn on.

Also looked at calibration repeatability between units. Resistor marked as 22k+680. Multimeter reads 23.7k, green/purple 24.4k, red/purple 21.4k, tony1.5 21.9k

comment:5 Changed 12 years ago by tonyforster

Temperature stability:
Measuring cpu temp /sys/devices/platform/via_cputemp.0/temp1_input versus measured R of nominal 22k+680 XO Tony1.5 TA V130 SKU99
T R
30000 21.87k
40000 21.89k
50000 21.91k
55000 21.96k

Crosstalk:
Measuring nominal 22k on left channel
R channel shortcircuit 20.61k
R channel opencircuit 20.73k

comment:6 Changed 12 years ago by tonyforster

Measure V34 and V36 are also buggy. They display a similar high noise fail state after aproximately 50% of boots. Switching to DC mode clears the fail state. Can then go to AC mode OK.

comment:7 Changed 12 years ago by tonyforster

So far, I haven't seen this fault on the XO-1.75 (or XO-1)

comment:8 Changed 11 years ago by walter

  • Resolution set to wontfix
  • Status changed from new to closed

I don't think this is something I can fix in Turtle Art. Happening at a lower level.

Note: See TracTickets for help on using tickets.