adamlaurie / rfidler Goto Github PK

$ rfidler.py /dev/ttyACM0 frequency
sending 'FREQUENCY'

This command never returns from rfidler.py. I see the results in minicom, but it breaks rfidler.command() somewhere.

Hi,
There was talk at some point on the forum about implementing Hitag2 Emulation, is there any progress on this, or any way I can get involved with its implementation?

Thanks,
Dan

I just received my Beta RFIDler in the post; while it looks all nice and green, there are no chips on the board and no place to provide power (well, I suppose I could hook up my car battery and try to jump start it.)

Hopefully the circuitry will not be arriving in a 2nd box, as my soldering skills might not be up to snuff. While you did say beta....

(Oh, it'd be awesome to have an addr to send things to, or a place for feedback; if this is the right place that's fine, but even a mention of that in the FAQ would rock.)

Hello,
This may be a fairly simple issue, but after twenty minutes of searching and a lot of different leads, I'm unable to locate the simplest thing: the udev rules described in the readme for Linux users.

You should link to the official udev rules and/or just include it in the repo.

Thanks.

Building with XC32 v1.32 completes OK, but flashing causes a verify failure. I've corrected all the issues I can see in procdefs.ld and also ensured we are linking against the v1.32 peripheral library, but to no avail...

Unitialized variables bugs up to commit 426dfcd

• firmware\Pic32\RFIDler.X\src\indala.c => indala64_get_uid => Uninitialized variable: bits
  • Code extract:

    //Parity check, count bits
    int bits;
    int i, n;
    for (i=0; i<16; i++)
    {
        if (response[i] >= 'a' && response[i] <= 'f')
            n = response[i] - ('a' - 10);
        else if (response[i] >= '0' && response[i] <= '9')
            n = response[i] - '0';
        else if (response[i] >= 'A' && response[i] <= 'F')
            n = response[i] - ('A' - 10);
        else
            return FALSE;
        bits += __builtin_popcount(n);
    }

• firmware\Pic32\RFIDler.X\src\sniff.c => do_sniff_pwm => Uninitialized variable: count
  This bug is critical as it can lead to very long loop depending on count value which is uninitialized
  • Code extract:

void do_sniff_pwm(unsigned int mingap, unsigned minpulse, unsigned int mesg_gap, BOOL nfcmode)
{
    BOOL            toggle;
    BOOL            abort= FALSE;
    unsigned long   count, pulsecount= 0L;
    unsigned int    len, gaps[DETECT_BUFFER_SIZE], pulses[DETECT_BUFFER_SIZE];

    // make sure local clock isn't running & switch to input
    stop_HW_clock();

    COIL_MODE_READER();
    READER_CLOCK_ENABLE_OFF(LOW);

    toggle= SNIFFER_COIL;

    // reader/tag mode - wait for 100 ticks to make sure we're settled
    if (!nfcmode)
    {
        toggle= SNIFFER_COIL;
        while(count < 100L)
        {
            while(SNIFFER_COIL == toggle)
                // check for user abort
                if(get_user_abort())
                    return;
            ++count;
            toggle= !toggle;
        }
    }
...

I think a step is missing from the plotter wiki tutorial:

$ rfidler.py /dev/ttyACM0 'set tag askraw' 'potset h 255' PLOT 500
sending 'SET TAG ASKRAW'
sending 'POTSET H 255'
Failed: No clock running!
$ rfidler.py /dev/ttyACM0 'VERSION'
sending 'VERSION'
0003-alpha

This is for a Beta tester unit -- are we supposed to update the firmware on the RFIDler, or is the firmware that shipped sufficient?

Thanks,

-Josh

As per discussion (http://rfidler.org/index.php?p=/discussion/21/new-rfidler-trouble-reading-awid26-or-hid-prox-tags) it would be good to have that support.
https://github.com/sk3tch/RFIDler/tree/forked

The "Windows" section in README.MD for flashing a new firmware version still only consists of "???".
The "Windows" and "MacOS" section of the "firmware" wiki page on Github are empty.

There is some information in the forum at
http://rfidler.org/index.php?p=/discussion/11/firmware-update-on-windows-using-hidbootloader-from-microchip-library-for-applications
but it does not tell where to get HIDBootloader.exe

There does not seem to be named releases on Github and no obvious version.h or similar file to look up what a current version number should look like.
So I have no idea if "0114-beta" the board tells me is terribly outdated or current and
no way of updating the firmware to the latest file from firmware/Pic32/RFIDler.X/dist/debug/production/RFIDler.X.production.hex

I have already copied the correct file to /etc/udev/rules.d and reloaded the rules. When I attempt to build the file in MPLABX my build fails with the following error. Using a clean install.

make[2]: *** No rule to make target '/opt/microchip/xc32/v1.33/pic32mx/lib/libmchp_peripheral_32MX795F512L.a', needed by 'dist/debug/production/RFIDler.X.production.hex'. Stop.

hi
at first I apologize for my bad english
Special thanks to Mr AdamLaurie for his great RFIDlr device
after weeks finally I could compile mcu and windows projects,but there is no usage of hitag2crack folder and its cracks source file!!
although Author(Kevin Sheldrakein) describes how to use these cracks by RFIDlr device in README file
is any one there who try that cracks ?
best regards

Windows complains about a wrong hash when trying to install rfidlercdc

I have just checked quickly the board (with Eagle) and following stuff could be improved for final version (about USB remarks 1/2/3 even if only USB 2.0FS is used and those rules are required for USB 2.0HS it is good to apply them) :

1. For USB: Route the differential pairs together.
2. For USB: USB signal shall be not under Crystal and to shall be as far as possible from quartz(X1).
3. For USB: Route the differential pairs (D+/D-) over unbroken ground planes or floods and with same size if possible.
4. Add a ferrite bead on USB VBUS (especially for analog part to avoid parastic problems) like Murata BLM21PG221SN1D FERRITE CHIP 220 OHM 2000MA 0805.
5. Add ESD protection on USB D+/D- (something like NXP PRTR5V0U2X DIODE ESD PROTECTION SOT143B)
6. Some PIC VDD pins have no decoupling capacitor (at least 100nF).
7. Decoupling capacitor(10nF) on VBUS/Power part C25,C28,C27,C26 are too far from the VDD pin (they shall be as close as possible).
8. VBUS (5V) signal have some wire less than 8mil could be problematic for voltage drop (R=710mOhm) and with an Imax of 0.64A and a total len of about 286mm (computed with Eagle6 length-freq-ri.ulp).
9. 3V3 signal have some wire less than 8mil could be problematic for voltage drop (R=1257mOhm) and with an Imax of 0.64A and a total len of about 506mm (computed with Eagle6 length-freq-ri.ulp).
10. 3V3 power from C18 to R23 could be simplified to avoid parallel 3V3 wire.
11. Components placement could be optimized to avoid all those vias and maybe a switch to 4 layers will be a must for noise immunity (especially for analog part) for a simplified routing and smaller board.
12. You should apply some standard Eagle DRU rules for cheap PCB on the board like http://www.seeedstudio.com/document/rar/SeeedStudio_2layer_DRU_no_angle_20140221.rar or ftp://imall.iteadstudio.com/PCBs/ITEADstudio_DRC.zip as there is lot of clearance problems.

C:\Projects\RFIDler\python>setup.py install
running install
running build
running build_py
creating build
creating build\lib
creating build\lib\RFIDler
copying RFIDler__init__.py -> build\lib\RFIDler
running build_scripts
creating build\scripts-3.4
copying rfidler.py -> build\scripts-3.4
running install_lib
creating C:\Python34\Lib\site-packages\RFIDler
copying build\lib\RFIDler__init__.py -> C:\Python34\Lib\site-packages\RFIDler
byte-compiling C:\Python34\Lib\site-packages\RFIDler__init__.py to init.cpython-34.pyc
File "C:\Python34\Lib\site-packages\RFIDler__init__.py", line 159
print '\r\n>>>', tosend,
^
SyntaxError: Missing parentheses in call to 'print'

running install_scripts
copying build\scripts-3.4\rfidler.py -> C:\Python34\Scripts
running install_egg_info
Writing C:\Python34\Lib\site-packages\RFIDler-1.0-py3.4.egg-info

C:\Projects\RFIDler\python>setup.py install

I am at a complete loss as to how I am supposed to get my RFIDler working. Is there a way to just download a program that has all I need to get it working? The instructions in the read me are confusing and beyond my expertise. I need a guide for beginners!

Could you just shorten the header and add a license file in firmware directory to avoid scrolling 482 header lines before to see the first line of code ?

It just stalls and never finishes

Current version: 0187-beta

RFIDler> version
0187-beta
RFIDler> autotag
  ASKRAW: 9<removed data>
  FSK1RAW: 
  FSK2RAW: 
  PSK1RAW: 
  PSK2RAW: 
  PSK3RAW: 
  HITAG1: 
  HITAG2: 
  EM4X02: 
  Q5: 
  HID26: 
  INDALA64: 
  INDALA224: 
  UNIQUE: 
  FDXB: 
  T55X7: 
  AWID26: 
  EM4X05: 
  TAMAGOTCHI: 
  HDX: 

http://rfidiot.org/ website seems to not be working ?

Hi,
I have problem with SNIFF-PWM list stored option, becouse when I do procedure on my RFIDler:
SET TAG HITAG2
SNIFF-PWM C
AUTORUN SNIFF-PWM S
SAVE
• Power RFIDler from USB battery
• RFIDler antenna on RWD, present tag (n times)
and comands "SNIFF-PWM L" return:
"No HiTag2 PWM stored"
where is the problem?

Would be nice, so more casual users don't need to set up a whole build environment.

Apologies if this already exists and I just haven't found it?

Would you consider dropping the Non-Commercial clause for the hardware portion of this project?

It looks like the Kickstarter wrapped up in 2015 which, as of this writing, is now over 4 years ago. I don't see much activity on the forums and, as far as I can tell, a pre-built boards are only available if people contact Aperture Labs directly.

Allowing for commercial use would free others to use, create and update the hardware design files without needing to contact you explicitly. Open source hardware projects could also use your hardware design files without having to re-invent them were you to drop the Non-Commercial clause.

win7 64bit complains about unsigned driver, even though catalog file is present.

Maybe the INF was edited after signing the CAT ?
Edit: just recognized, its the mchpcdc.cat and customized mchpcdc.inf from the MLA, actually not a really signed driver package. Maybe the CAT should simply be removed.

A permanent 'user-friendly' device name is created for RFIDler in the /etc/udev/rules.d/71-rfidler-lf-cdc-blacklist.rules file. However, it ends up pointing to the raw usb device, not the CDC interface:

$ ls -l /dev/ttyACM3
crw-rw-rw- 1 root dialout 166, 3 Jun 13 14:24 /dev/ttyACM3
$ ls -l /dev/RFIDler
lrwxrwxrwx 1 root root 15 Jun 13 14:24 /dev/RFIDler -> bus/usb/002/056

and opening this device in a serial terminal doesn't work.