’ Bit 5 of the PB_mode byte (aliased as user_display_mode below) indicates when
’ the user selects the “User Mode” on the OI. PB_mode.bit5 is set to 1 in “User Mode”.
’ When the user selects channel, team number, or voltage, PB_mode.bit5 is set to 0
’ When in “User Mode”, the eight Robot Feedback LED are turned OFF.
’ Note: “User Mode” is identified by the letter u in the left digit (for 4 digit OI’s)
’ Note: “User Mode” is identified by decimal places on the right two digits (for 3 digit OI’s)

user_display_mode VAR PB_mode.bit5

User Mode turns off your status LEDs, and then helps you… how? I guess what I’m asking is, what does it do?

On the 7 segment display of the operator interface, it will display the value that you choose.

Last year, that display could show team number, channel number, and battery voltage. Now it can display those as well as the user display.

The following code is where you set which variable is to be displayed:

if user_display_mode = 0 then 'User Mode is Off


else 'User Mode is ON

  out8    = p1_y.bit0		' Set ouput bits to display p1_y variable
  out9    = p1_y.bit1
  out10   = p1_y.bit2
  out11   = p1_y.bit3
  out12   = p1_y.bit4
  out13   = p1_y.bit5
  out14   = p1_y.bit6
  out15   = p1_y.bit7


Change the p1_y to any byte variable to display it.

this is an example of a good idea gone horribly wrong.

when you go into user mode, it kills all your LED’s because the stamp only has 8 pins open after all the other uP and misc functions. this happens to be the magic number to drive an 8 segment LED display as well.
the only way for IF to feasibly do it and not make things too complex was this.

practically… the function is useless… alot more usefull to have indicator LED’s


So… wait… we toggle into UserDisplayMode, we lose our status LEDs, and we get to see how far we’ve got the joystick pushed?!? Why would you want to do that!!!

you can set it to read other things… but whenever you are in usermode… only what you send into the display is visible… you loose all your LED’s

( and it’s only p1_y… the left one is a secret ^.^ )

I believe this might be useful during the autonomous mode. You can’t send any messages to the RC but perhaps the RC sends messages to the OI.

Maybe you want to show the process the robot is on in the automated process.

I was thinking of using it for the person who is setting the switches on the RC for the different programs to make sure they have the right bits to correspond with a number.


temp var byte

temp = sw8 <<1 + sw7 <<1 …<<1 + sw1

essentially if there are only a few switches
temp = sw2 <<1 + sw1
works as well

right to

  1. Follow Line - 00000001 - Display: 1
  2. Seek and destroy - 00000010 - Display: 2
  3. Dead Reckoning - 00000011 - Display: 3

The person setting it, might have a paper with a list and corresponding numbers.

I don’t know this is just a sample idea, I’m not sure if the user-display still works on the OI in the automated mode.

Maybe keeping it concealed by numbers would also keep anyone else from understanding what program you are actually using.

There might even be a more practical use. Why not HOOK up the yaw rate sensor to the user input, then you can balance with a guide. Bleah, but who needs to balance, whatever.

Theres some uses I guess.

i would think that in auto mode, you’d be better off with the status lights. then, if something goes horribly wrong, you can tell, and hit the E-Stop button as fast as you can. knowing a 0 - 255 number value won’t help us here…

well, having non programmers manipulating BITS isnt a good thing…

not that many people speak binary fluently, if your having 4-8 switches…

Its just a good way to make sure your not making a mistake. It was just a suggestion. Anyways, if something goes wrong, would you not see it? I think it would be more valuable to see what your program is suppose to do based on the number vs what its actually doing from sight.

i really wish they would just have like a 4x16 LCD module on the thing. I hate LED displays!!! I think that we should form a petition to have this changed for next year. Its not hard to engineer into the RC at all. I also wish that we could pass more detailed info to the dashboard port.

… I love my LEDs…:rolleyes:

i find the LEDs much more helpful. i can program numerous things to happen to them, each which could explain an important thing happening on the robot. considering the fact that i’ll probably be a driver, if i design the UI for the robot, i’ll know what each LED means. any other drivers, will not only have to prove themselves to the team, but learn which LED means what, or else they can’t drive. sure, it’s crude, but hey, it works.

It could help with setting the trim on the joysticks too. You could use a push button to toggle through all kinds of data.

PS if you want to neaten (and shorten) your code alot, use OUTH instead of each pin

who says u have to do away with the LEDS. A serial LCD can be contrulled using one uP pin which still leaves room for LEDS. Just thing of all the stuff that could be displayed. (i love LCDs. I even modded one into my computer.)