Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
Hi, just wondering about the 4 Blue LEDs on the RDV4
I can see the function calls for LED A, B,C and D (as they would have been stock to previous versions).
Are the 4 Blue LEDs controllable from firmware ?
Thanks
Offline
Nop, the four blue power leds is not controllable from fw.
Offline
ok, no problem. Thanks for the response.
Offline
Is there a way for the proxmark3 CLI tool to control the LEDs? If not, could it be added to the "hw" subcommands?
Thanks
Offline
No. You can control the A,B,C,D leds via code. Shouldn't be hard to implement a command to allow the client to set them.
Offline
@pacmandu What are you trying to do ?
The reason I asked my question was I saw led A B C and D as being system/status LEDs that will be turned on and off by existing code. I saw the blue as being new and always on, so IF the where connected to the micro controller, then these could be user LEDs (but they are not).
I am assuming what you would like to do is have a script file that works something like
- Turn off all leds
- Turn on led A (to give you feed back, in stage 1)
- Turn on led B (we are now at stage 2)
- Turn on led C (Found xyz)
- Turn on led D (in last stage)
- Turn off all leds (all done)
While I agree it could be done, you would need to update all the OS calls to LED x on/off to be disabled IF the user actions something. if this is not done, then they may get turned on/off by existing code.
I am just brain storming here.
But something like LED_A (status), LED_B (status), LED_C (status), LED_D (status)
Where status could be
0 - As per existing code/OS control.
1 - User Turned On (OS will ignore existing calls)
2 - User Turned Off (OS will ignore existing calls)
Given the above, then do we need to consider some way to auto return to OS status calls (e.g. power cycle the unit would do it), but if you turn them all off, and forget to return control to the OS then you may think the unit is off/lost power (non rdv4). Would that be ok?
Just some thoughts.
Offline
Thanks for the feedback! I am only curious because I implemented a proof of concept script in Bash and wrapped around the client and wouldn't mind providing visual feedback on the RDV4 while the script is running on Linux system. A future version would be in Lua or C as a standalone version but with bluetooth capability as an option it's not a high priority to convert it right now when having a remote laptop for computational analysis is more preferred anyways.
Too expand on what mwalker suggested for the led behavior list, yes, that's exactly what I am going for. I don't mind if existing calls change the leds because after each command I can just set them to what the overall status is again anyways and seeing the existing calls in action is also a desired effect. The only other led behavior I would add is for them to flash all on and then off as a final "success" status.
I'll be honest and admit that I am a python and bash person and C(++) is not my strong suit at all. I'll try struggle bus'ing with this and see if I can contribute a simple feature request as a way to get my feet wet with contributing to a great project and learning C(++).
Last edited by pacmandu (2019-06-18 04:55:15)
Offline
Pages: 1