Menu button delay - deliberate coding? Or I did something?
Menu button delay - deliberate coding? Or I did something?
I was messing around with the switch circuitry today. I never noticed before that the Menu button isn't as responsive as the others... is it just that I didn't notice? Or did I mess something up? I suspect its how its programmed, but I thought I'd ask.
When I first power up the radio and it gives me the eeprom and/or witch and/or alarm warning and says "press any button to discard" (or however its worded)... at that point, quickly tapping the Menu button does as I'd expect. In other words... the press is recognized.
But after I'm on the homescreen, if I quickly tap (press and release with no pause) the menu button, it does nothing. I have to delay for maybe a quarter of a second before the menu comes up. Normal? Or caused by my meddling?
- Steven
When I first power up the radio and it gives me the eeprom and/or witch and/or alarm warning and says "press any button to discard" (or however its worded)... at that point, quickly tapping the Menu button does as I'd expect. In other words... the press is recognized.
But after I'm on the homescreen, if I quickly tap (press and release with no pause) the menu button, it does nothing. I have to delay for maybe a quarter of a second before the menu comes up. Normal? Or caused by my meddling?
- Steven
Re: Menu button delay - deliberate coding? Or I did somethin
Yes, in the home screen a short press on the MENU button doesn't do anything.
It's designed that way.
It's designed that way.
Z
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
Re: Menu button delay - deliberate coding? Or I did somethin
Figured so.
So... what's that capacitor do? lol. The mucking around I did resulted in the SMT cap that's below the SCK/menu pin coming off its pad. So I removed it entirely and the only effect I thought I noticed was a less responsive menu button (that you've now confirmed is by design). What are those caps there for? There's one on every input line. Looking at Atmega datasheets I've so far seen no mention that a cap is required on an input line.
So... what's that capacitor do? lol. The mucking around I did resulted in the SMT cap that's below the SCK/menu pin coming off its pad. So I removed it entirely and the only effect I thought I noticed was a less responsive menu button (that you've now confirmed is by design). What are those caps there for? There's one on every input line. Looking at Atmega datasheets I've so far seen no mention that a cap is required on an input line.
Re: Menu button delay - deliberate coding? Or I did somethin
Could be some sort of debounce mechanism?
Don't really know. Have to look at the schematics.
Don't really know. Have to look at the schematics.
Z
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
BEWARE - WE ARE IN THE AIR!!!
What goes up... Should be controlled by a 9X!
- MikeB
- 9x Developer
- Posts: 17990
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Menu button delay - deliberate coding? Or I did somethin
I think the caps are there for RF suppression. Perhaps not suprising since it is a RF transmitter!
Mike.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Menu button delay - deliberate coding? Or I did somethin
The schematics aren't very telling. I guess it is debouncing, but obviously its not doing much. Do you software debounce? Mike - I suppose you could be right... but I can't see how slowing down a i/o signal every-so-slightly would make a lick of difference for RF. Still, perhaps its a "best practices" thing for an "every little bit helps" attitude.
Re: Menu button delay - deliberate coding? Or I did somethin
Mike is correct , the caps shunt high frequencies/noise to ground.
They are not there for debouncing.
Remember ... as the frequency goes up , the capacitors "resistance" goes down.
The series resistor is good practice to help reduce EMI and ESD events to the port pins.
-Brent
They are not there for debouncing.
Remember ... as the frequency goes up , the capacitors "resistance" goes down.
The series resistor is good practice to help reduce EMI and ESD events to the port pins.
-Brent
Re: Menu button delay - deliberate coding? Or I did somethin
What "high frequencies" though?
Clicking a simple tactile switch produces "high frequencies"?
Learn something new every day
Clicking a simple tactile switch produces "high frequencies"?
Learn something new every day
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: Menu button delay - deliberate coding? Or I did somethin
I suspect they were worried about RFI from the 1 watt 35/72 mhz module that the transmitter was originally designed for.
Pat MacKenzie
Pat MacKenzie
Re: Menu button delay - deliberate coding? Or I did somethin
found this paper on the subject: http://www.ti.com/lit/an/szza009/szza009.pdf
Section 2.2.5 in particular. If I understood it (which is a leap), its about reigning in noise from the microprocessor itself. Right?
Interesting stuff! (and at the same time... so extremely boring)
Section 2.2.5 in particular. If I understood it (which is a leap), its about reigning in noise from the microprocessor itself. Right?
Interesting stuff! (and at the same time... so extremely boring)
-
- Posts: 236
- Joined: Tue Dec 27, 2011 11:19 pm
- Country: -
- Location: Don Mills, Ontario
Re: Menu button delay - deliberate coding? Or I did somethin
That makes a lot of sense. Part of the approval would be minimum unintended transmissions.
Re: Menu button delay - deliberate coding? Or I did somethin
Clicking the switch causes the contacts to bounce (ringing) for a short period of time.
The Resistor limits the input current , in case of a static zap to the switch.
If there were high speed outputs , then the resistors slow things down a bit to help with radiated EMI.
The ARM chip in the new board , has built in 56 ohm resistors.
FYI - There are no caps on the 6 menu keys on the ERSKY9x board, just the series resistors.
-Brent
The Resistor limits the input current , in case of a static zap to the switch.
If there were high speed outputs , then the resistors slow things down a bit to help with radiated EMI.
The ARM chip in the new board , has built in 56 ohm resistors.
FYI - There are no caps on the 6 menu keys on the ERSKY9x board, just the series resistors.
-Brent
Re: Menu button delay - deliberate coding? Or I did somethin
then I'm confused... didn't you just agree with Mike that the caps are necessary for limiting EMI?
Re: Menu button delay - deliberate coding? Or I did somethin
Mike said the caps were for eliminating RFI , which could get picked up by the board traces , or the wires connected to the external switches and pots.
These all act as antennas, and could pickup stray signals / noise and couple it into the micro. By putting a capacitor on these inputs , any noise picked up,
is shunted to ground , and not into the micro.
The resistors also help filter noise from the signal , and add ESD protection.
Things like SPI signals can cause noise emission , because they are driving the port pins in the 2Mhz range.
You cannot put caps on these signals , as it would slow them down to much to be useful digital signals. (just look at the problems it causes the AVR
programmers , that cannot overcome the capacitors on the programming lines ... as you know....
If the keys were being scanned in the Mhz range , then , there could be radiated noise (EMI) , but the scanning is done in the 100Hz range , so
no real noise is generated.
A resistor in series with a output pin , slows down the current enough to help stop ringing in the high speed lines.
This is all about transmission line theory ....AC circuit theory , it is not like the DC theory most learned.
The ARM micros run the external clocks at lower frequency for reduced EMI , and then use a PLL to internally multiply the signal into the 100Mhz range. Which is
in the FM radio band. , so any long external traces running a clock speed could transmit RF.
Bypass capacitors across the power supply, spread around the board , can greatly reduce noise problems as well.
In General.
A input resistor say 100R to 1K
A output resistor say 20R to 200R
A input Cap say 0.01 to 0.47uf
A output Cap say 50pF to 1000pF
inputs should be filtered , outputs should be limited..
Have I confused you more , or is this clear as MUD ?
-Brent
These all act as antennas, and could pickup stray signals / noise and couple it into the micro. By putting a capacitor on these inputs , any noise picked up,
is shunted to ground , and not into the micro.
The resistors also help filter noise from the signal , and add ESD protection.
Things like SPI signals can cause noise emission , because they are driving the port pins in the 2Mhz range.
You cannot put caps on these signals , as it would slow them down to much to be useful digital signals. (just look at the problems it causes the AVR
programmers , that cannot overcome the capacitors on the programming lines ... as you know....
If the keys were being scanned in the Mhz range , then , there could be radiated noise (EMI) , but the scanning is done in the 100Hz range , so
no real noise is generated.
A resistor in series with a output pin , slows down the current enough to help stop ringing in the high speed lines.
This is all about transmission line theory ....AC circuit theory , it is not like the DC theory most learned.
The ARM micros run the external clocks at lower frequency for reduced EMI , and then use a PLL to internally multiply the signal into the 100Mhz range. Which is
in the FM radio band. , so any long external traces running a clock speed could transmit RF.
Bypass capacitors across the power supply, spread around the board , can greatly reduce noise problems as well.
In General.
A input resistor say 100R to 1K
A output resistor say 20R to 200R
A input Cap say 0.01 to 0.47uf
A output Cap say 50pF to 1000pF
inputs should be filtered , outputs should be limited..
Have I confused you more , or is this clear as MUD ?
-Brent
Re: Menu button delay - deliberate coding? Or I did somethin
I'm good, thanks!