HBBR Basic

  • Increase font size
  • Default font size
  • Decrease font size

Part3: Beeping brick analysis

E-mail Print PDF
User Rating: / 1
PoorBest 

Sound analysis

To generate sound ARM MCU toggles PA17 high and low, this digital signal drives power amplifier and is then fed into a loudspeaker. Captured sound wave shown below corresponds to this signal. As can been seen from the analysis the basic frequency is about 246.34 Hz which is lower then the intended one of 1000 Hz. Spectral analysis also confirms this as we can find a peak at around 246 Hz which matches the first calculation.

 

 

 

The problem is in the Sub delay() which has not yet been calibrated. However, the correction to get the 1000 Hz frequency is fairly simple, all we need to do is to shorten the delay about 4.06 times (246.34 / 1000 ~= 4.06). Since 4.06 is close to 4 we will use 4 to simplify calculation while keeping the error to about 1.5 percent.


Corrected Sub delay() contains following line

d = d \ 4 ' integer division


After the change due to distortions sound wave looks very different but the spectral analysis confirms that the main component is 977 Hz. Which is about 2.5% less then the intended 1000 Hz but close enough for our purpose. At his point we can declare Sub delay() to be calibrated.





Frequency analysis

 

 

Beeping pattern


The observed beeping pattern is explained by the fact that there are 2 microcontrollers on the NXT brick board and it is not the ARM MCU that controls the power flow. Power to the ARM MCU is controlled by the AVR ATMEGA48 which remains on at all times and reacts to the user pressing power button or to a power up event. The simplified sequence of events looks like this:

1 power is applied or the power button is pressed
2 ATMEGA48 does some housekeeping chores which takes about 30 ms
3 check that battery voltage is in range
4 turn on the power to ARM CPU
5 wait 500 ms for battery voltage to stabilize
6 check that battery voltage is in range
7 set communication timer to 2000 ms
8 wait for ARM to communicate
9 if communication timer expired toggle the power then set communication timer to 500 ms
10 if no communication from ARM then repeat from step 8
11 ARM has communicated then continue

ARM MCU has initially 2000 ms to send OK message back to the ATMEGA48, later this time is reduced to 500 ms. Communication between ARM and ATMEGA48 MCUs is accomplished through I2C bus where ARM is always the master and is using hardware I2C peripheral to achieve 380Kbit/s transfer speed. ARM has to send specific message to the ATMEGA48 to confirm that it is operating OK and that ATMEGA48 should not turn of the power

 

ARM AVR communication will be the topic for the next installment