开云体育

Date

Locked Re: Java.lang.NullPointerException

 

开云体育

Thanks for your reply, Cliff.
This newbie stumbled on solution.


On Apr 28, 2023, at 11:54 PM, Cliff Anderson <cliffaa@...> wrote:

?Joe,

Without more information, we are unable to figure out how to do more than provide some kind of broad brush guess.? At a minimum, the explicit wording of the error message and the context that led up to it are needed.? The more details you provide, the narrower our help will be.?

Copy the text of either the log/session.log file or from the JMRI System Console window into your next reply.? If you need help finding either of these, use the Help menu item to either identify the locations to get to the log file or to open the Console.

For more information, read Peter's instructions concerning the relevant details at?/g/jmriusers/topic/admin_how_to_ask_your/24915998?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,24915998?

Historically, guessing is not productive.

Cliff in Baja SoCal


Locked Re: RFID Connectivity #rfid

 

MFRC522, Uno, Ethernet and Serial

Tom,

sorry for the delay in posting this sketch. I wanted to make sure it was the right one before I did so. As you may have guessed, I assign version numbers to the sketches so that I know which one is which! This one I call Version 4.

//Multi Reader MCU Combo for Serial and Ethernet v4

//MFRC522 ? ? Nano/Uno ? ? ?Mega
//3.3v ? ? ? ? ?3.3v ? ? ? ?3.3v ? ? ?
//RST ? ? ? ? ? ? See #define
//GND ? ? ? ? ? GND ? ? ? ? GND
//IRQ ? ? ? ? ? ? Not Used
//MISO ? ? ? ? ?D12 ? ? ? ? D50
//MOSI ? ? ? ? ?D11 ? ? ? ? D51
//SCK ? ? ? ? ? D13 ? ? ? ? D52
//SS/SDA ? ? ? ? ?See #define

//Arduino Mega
//SS pins: 5, 6, 7, 8, 9, A0, A1, A2
//RST pins: 22, 23, 24, 25, 26, 27, 28, 29

//Arduino Uno and Nano
//SS pins: 5, 6, 7, A0, A1, A2
//RST pins: 2, 8, 9, A3, A4, A5

// Import Libraries
#include <SPI.h> ? ? ? ? ? // SPI library for communicating with the MFRC522 reader
#include <MFRC522.h> ? ? ? // MFRC522 library for reading RFID cards
#include <Ethernet.h> ? ? ?// Ethernet library for the Ethernet shield
?
// Ethernet configuration
byte mac[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED};
IPAddress ip(192, 168, 1, 100);
unsigned int serverPort = 80; ?// Replace with the desired port number
EthernetServer server(serverPort);
?
// Define the SS (Slave Select) and RST (Reset) pins for each reader
#if defined(ARDUINO_AVR_UNO) || defined(ARDUINO_AVR_NANO)
const uint8_t ssPins[] = {5, 6, 7, A0, A1, A2};
const uint8_t rstPins[] = {2, 8, 9, A3, A4, A5};
const uint8_t readerAssignment[] = {1, 2, 3, 4, 5, 6}; // Assign reader numbers based on SS and RST pins
#elif defined(ARDUINO_AVR_MEGA2560)
const uint8_t ssPins[] = {5, 6, 7, 8, 9, A0, A1, A2};
const uint8_t rstPins[] = {22, 23, 24, 25, 26, 27, 28, 29};
const uint8_t readerAssignment[] = {1, 2, 3, 4, 5, 6, 7, 8}; // Assign reader numbers based on SS and RST pins
#endif
?
const int numReaders = sizeof(ssPins) / sizeof(ssPins[0]);
const char readerID[] = {'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H'};
?
struct RFIDReader {
? char id;
? uint8_t ssPin;
? uint8_t rstPin;
? MFRC522 mfrc522;
? byte nuid[7];
?
? RFIDReader() : id(0), ssPin(0), rstPin(0), mfrc522(MFRC522(0, 0)) {}
};
?
RFIDReader readers[numReaders];
EthernetClient client;
?
void setup() {
? Serial.begin(9600);
? SPI.begin();
? pinMode(10, OUTPUT);
? digitalWrite(10, HIGH);
?
? // Set pin 53 as OUTPUT for the Arduino Mega 2560
? #if defined(ARDUINO_AVR_MEGA2560)
? ? pinMode(53, OUTPUT);
? #endif
?
? // Explicitly deselect the SD card if not in use
? pinMode(4, OUTPUT);
? digitalWrite(4, HIGH);
?
? // Initialize the Ethernet connection
? Ethernet.begin(mac, ip);
? delay(1000); // Allow the Ethernet shield to initialize
?
? for (uint8_t i = 0; i < numReaders; i++) {
? ? readers[i].ssPin = ssPins[i];
? ? readers[i].rstPin = rstPins[i];
? ? readers[i].id = readerID[readerAssignment[i] - 1]; // Assign the reader ID based on readerAssignment array
? ? readers[i].mfrc522 = MFRC522(readers[i].ssPin, readers[i].rstPin);
? ? readers[i].mfrc522.PCD_Init();
? ? readers[i].mfrc522.PCD_SetAntennaGain(readers[i].mfrc522.RxGain_max);
? }
?
? server.begin();
}
?
void loop() {
? if (!client.connected()) {
? ? client.stop();
? ? client = server.accept();
? ? if (client) {
? ? ? Serial.println("Client connected");
? ? }
? }
?
? if (client.connected()) {
? ? for (uint8_t i = 0; i < numReaders; i++) {
? ? ? if (readers[i].mfrc522.PICC_IsNewCardPresent() && readers[i].mfrc522.PICC_ReadCardSerial()) {
? ? ? ? for (uint8_t j = 0; j < readers[i].mfrc522.uid.size; j++) {
? ? ? ? ? readers[i].nuid[j] = readers[i].mfrc522.uid.uidByte[j];
? ? ? ? }
?
? ? ? ? byte checksum = readers[i].nuid[0];
? ? ? ? for (uint8_t j = 1; j < 5; j++) {
? ? ? ? ? checksum ^= readers[i].nuid[j];
? ? ? ? }
?
? ? ? ? // Send output to Serial connection
? ? ? ? Serial.write(readers[i].id);
?
? ? ? ? // Send output to Ethernet client
? ? ? ? client.write(readers[i].id);
?
? ? ? ? for (uint8_t j = 0; j < 5; j++) {
? ? ? ? ? // Send output to Serial connection
? ? ? ? ? Serial.print(readers[i].nuid[j] < 0x10 ? "0" : "");
? ? ? ? ? Serial.print(readers[i].nuid[j], HEX);
?
? ? ? ? ? // Send output to Ethernet client
? ? ? ? ? client.print(readers[i].nuid[j] < 0x10 ? "0" : "");
? ? ? ? ? client.print(readers[i].nuid[j], HEX);
? ? ? ? }
?
? ? ? ? // Send output to Serial connection
? ? ? ? Serial.print(checksum < 0x10 ? "0" : "");
? ? ? ? Serial.print(checksum, HEX);
?
? ? ? ? // Send output to Ethernet client
? ? ? ? client.print(checksum < 0x10 ? "0" : "");
? ? ? ? client.print(checksum, HEX);
?
? ? ? ? // Send output to Serial connection
? ? ? ? Serial.write(0x0D);
? ? ? ? Serial.write(0x0A);
? ? ? ? Serial.write('>');
?
? ? ? ? // Send output to Ethernet client
? ? ? ? client.write(0x0D); // CR
? ? ? ? client.write(0x0A); // LF
? ? ? ? client.write('>'); ?// ETX replaced by '>'
?
? ? ? ? readers[i].mfrc522.PICC_HaltA();
? ? ? ? readers[i].mfrc522.PCD_StopCrypto1();
? ? ? }
? ? }
? }
}


to I will try the PN532 version and play about with the WeMos version and see what I get.

Steve


Locked Re: Which Dapol Imperium do I pick from the JMRI list? #definitions

 

I am just wondering if 2 are been offered as the lights in one end without the motor and decoder still need to communicate as I’ve only fitted the 1 decoder on the motor and which housed the blanking plate.?


Locked Re: Loco moving only during sensing decoder type | Decoder Pro

 

At Sat, 29 Apr 2023 13:11:45 -0700 "Handrail-18" <thomas.mclaughlin2@...> wrote:


Recently bought two locos and whenever I put them on the programming track
with JMRI, the trains only move incrementally backwards and selects multiple
possible decoders (none of which work). Using throttler on the decoder
address it sensed did nothing. Is there a reason for this or a cause for
concern? Video below highlights the issue,
You cannot actually run the locos on the programming track. (Yes the trains
*might* move a little while reading CVs.)




I have a Bachman 60804 HO scale Great Northern GP30 Diesel locomotive #3007 and am using a DCCEX command station.

Any help/advice is appreciated,
Thomas






--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
-- Linux Administration Services
heller@... -- Webhosting Services


Locked Loco moving only during sensing decoder type | Decoder Pro

 

Recently bought two locos and whenever I put them on the programming track with JMRI, the trains only move incrementally backwards and selects multiple possible decoders (none of which work). Using throttler on the decoder address it sensed did nothing. Is there a reason for this or a cause for concern? Video below highlights the issue,



I have a Bachman 60804 HO scale Great Northern GP30 Diesel locomotive #3007 and am using a DCCEX command station.

Any help/advice is appreciated,
Thomas


Locked Re: I have apparently created a loop or message storm in Loconet - I don't know if it's JMRI or not -- any suggestions on how to diagnose?

 

Well, I changed all the masts (about 35 of them) to a send count of 1 and the problem went away. That MIGHT have been the answer, or I did something different in the startup sequence, or it was something entirely different. We may never know.?

Thanks for the suggestion -- it was probably a good idea to do even if it wasn't the cause of the problem (or maybe it was?).

Scott Walton

On Sat, Apr 29, 2023 at 3:05?PM Ken Heywood <kheywood@...> wrote:
Are you using masts? If so, set the Send Count to 1, not 3. See how that works.
--
Ken
NYNH&H, Old Colony Division, Cape Cod Branch (1949-1959)
[DB150][PR3][QuadLN_S][JMRI 5.3.5]



--
Scott Walton


Locked Re: I have apparently created a loop or message storm in Loconet - I don't know if it's JMRI or not -- any suggestions on how to diagnose?

 

Are you using masts? If so, set the Send Count to 1, not 3. See how that works.
--
Ken
NYNH&H, Old Colony Division, Cape Cod Branch (1949-1959)
[DB150][PR3][QuadLN_S][JMRI 5.3.5]


Locked I have apparently created a loop or message storm in Loconet - I don't know if it's JMRI or not -- any suggestions on how to diagnose?

 

I have been working with my panels (current version at /g/jmriusers/files/ProblemsBeingWorkedOn/Scott_Waltons_problem/PRR_West_CTC_cleaned_fourth_reset.xml)?getting the Signals correct (especially around the double crossovers). I got those apparently correctly and managed to get several Transits to correctly circle the railroad (mostly - a couple of pauses here and there). I went to work on it again and when I turned on power to the railroad, I noticed that the Loconet became VERY busy and never went idle. When I looked at the Loconet monitor, there were many "Send IMM Packet command" messages and most were rejected as the buffer was full. I turned off power to the railroad and then restarted JMRI -- the same situation recurred. I again turned off the railroad and this time started JMRI on a different computer, connected to the same railroad. I started a monitor capturing the Loconet data. The messages didn't start again I restarted the PanelPro with the panels in the files section. Then the messages started again, but the curious thing is that they didn't stop when I exited PanelPro, so there must be something in the LocoNet devices that is either sending or resending these messages. The Monitor log has been upload to the same file area (/g/jmriusers/files/ProblemsBeingWorkedOn/Scott_Waltons_problem/monitorLog-alpha-full3.txt). No errors are showing in the System Console window.

The environment is:
Windows 11, Java 11, command station is Digikeijs DR5000 with DR5088RC Railcom readers, and RR-CirKits devies (SignalMan, TowerMan, MotorMan, TC-64, TC-64 MKII). Any suggestions on how to narrow down this problem. I think it would help if I was able to decipher where the Send IMM packets were addressed.

Scott Walton


Locked Which Dapol Imperium do I pick from the JMRI list? #definitions

 

Dear All,

I have just placed my Bachmann MPV on the test track to let JMRI read the information to be able to add it to my Roster.?

I have fitted a Dapol Imperium1 21-pin inside and have been running fine before hand. ?My question please I which decoder do I choose from the JMRI decoders listed under Dapol Limited > Imperium Decoders > 2 options are given either 860015 or 860019? ?What is the difference please?

Kind regards
Duncan


Locked Re: Question about JMRI operations #operationspro

 

And I should apologize, as I may have miscommunicated in an earlier post when I said..
...you can dial down the number of pages if you lower the route detail to the middle detail (check the middle of the three choices).? Also reset the font size to minimum of 7 for the report.
I should have pointed out that there are 2 detail Levels you can adjust.? Both are found in the?Trains Window--->Tools--->Build Report Options.

The first is the "Detail Level" and this is what I think you may have changed based on the build report you posted.? However, this level should be left on "Very Detailed", which, on the version of JMRI?(v. 4.22)?you are using, should be the 3rd button.
The second detail level is called "Router Detail Level" and it only becomes active when you select "Very Detailed" from the Detail Level section.? This is the button to which I was referring previously when I mentioned lowering of a detail level...

So, to reiterate, in the Build Report Options window, under the section labelled Detail Level, select the button labelled "Very Detailed", and under the section labelled Router Detail Level, select the button labelled "Normal".
And while in the?Build Report Options?window, consider lowering the font size to 7, as this makes wrapping-text less of an issue in reading the build reports...?

Happy to help, hope it helps,
<Pete Johnson>


Locked Re: RFID Connectivity #rfid

 

Blair,

Not pot stirring at all! Lol! All useful comments. Looking at my test rig, it is a rats nest of jumper cables. They are easily disturbed and a bit confusing at times. I can't see anyone wanting to use what we've done if it ends up like that!

So basically, I was thinking of trying neaten it all up a bit. I thought that up to eight sockets could be used to plug the readers into. Then the seven wires from each reader can be easily routed to where they need to be. The question is, where do they need to be with three different boards!

I felt the easiest thing would be to have an on board Nano socket to directly plug a Nano into. If you want Ethernet, than that could plug in with the Nano. Would you need an Uno as the Nano can do what the Uno can? So that just leaves the Mega. So I thought a row of breakout screw terminals could be present to allow wired connection to a Mega, or indeed an Uno if you realky wanted.

Although we haven't sorted this out yet, the pcb might also have to accommodate a 9v jack, 3.3v voltage regulator, level shifters and possibly a multiplexer. I'm not sure how we accommodate the Seeed readers.

Who is it aimed at? Anyone who wants a cheap RFID system. After all this, I would certainly have a few! You are right, there might be a bigger audience over on the RFID group, but I think most of them are keeping an eye on this thread too!

Keep the thoughts coming.

Steve


Locked Re: RFID Connectivity #rfid

 

Tom, Steve

Here comes that pot-stirrer again.? What/who is the intended target for PCBs?? I agree, a discussion needs to be had about essential/wanted/desired features to put things into perspective. Also, although these boards would feed into JMRI, is this something that should be hived off to the RFID list, instead?? It might get a larger audience that way.

I'd like to contribute, but let's figure out the ground rules first.

Blair

The PCB stuff is a different story entirely since there are a LOT of
considerations we have tossed around here in terms of the level of versatility we'd LIKE to >>have. I imagine that the PCB could use enable/disable jumpers for a slew of function types, but the electrical components we will need and how they connect

correctly may get complicated fast, especially if we want the thing
to work with all 3 board types.


Locked Arduino

 

For some reason my email server has lost all the jmri emails I saved. Also many other folders as well are empty.

I want to find the info with links to the Arduino project that tells you how to setup jmri on the Arduino so it runs the layout including detection.
someone has created all the files you need and what to do from start to finish

does anyone have that info

tony


Locked Re: RFID Connectivity #rfid

 

On Sat, Apr 29, 2023 at 07:42 AM, <stephenjohnson500@...> wrote:
So far, I've really only tested one reader with an Uno for these sketches. We need to test them on Nano's and Mega's to be sure. I also need to test multiple readers once the hardware has arrived. Then we can see what issues, if any, we get with 8 readers into a Mega. We might have to use a multiplexer and this would need to be added into some of the sketches.?

Once we've done that, I guess it's time to look at an easy pcb board for connections. I quite liked the idea of a Nano plugging into some headers on the pcb. I see you can get an Ethernet Shield for a Nano too? think it would also be useful to make provision for connections to Uno's and Mega's.

What are your thoughts?
Steve,

If the sketch works on the Uno, it will work on the Mega, which I can test here tonight or tomorrow. I spent a LOT of time ensuring the pin assignments are appropriate for all 3 board types and am pretty confident that the sketch should also work as expected on the Nano and Mega. As far as the MUX, I have a MFRC522 serial sketch for using a MUX. The code for doing that is fairly straight forward if we need it. The PCB stuff is a different story entirely since there are a LOT of considerations we have tossed around here in terms of the level of versatility we'd LIKE to have. I imagine that the PCB could use enable/disable jumpers for a slew of function types, but the electrical components we will need and how they connect correctly may get complicated fast, especially if we want the thing to work with all 3 board types. Don't get me wrong, it IS absolutely doable. ANYTHING is when it comes to electronics and coding. I just want you to fully grasp that the PCB aspect of this will be difficult at times.


Tom


Locked Re: Does type of DCC decoder matter for JMRI?

 

Thank you! So, the board that came with my loco had an internal dcc decoder on the big main board? I didn't even know that was possible haha. I am going to take your advice and just replace the main board with the?NCE board replacement decoder Bach-dsl and hope it gets sensed by JMRI.

Thank you,
Thomas


Locked Re: RFID Connectivity #rfid

 

On Sat, Apr 29, 2023 at 07:42 AM, <stephenjohnson500@...> wrote:
I like whatt you did with the PN532 sketch where it flashes the led for the number of readers and lists which ones are connected to which pins. That would be quite nice to have on the MFRC sketches too.
Steve,

As soon as you confirm for me the working MFRC522 Ethernet sketch, I can add the debugging messages and blinks.


Tom


Locked Re: Zimo Decoder MS950 and MS990 Definitions #zimo

 

I would like to learn how to make the changes. ?How do I get started.

Michael Carney


Locked Re: RFID Connectivity #rfid

 

PN532, Ethernet, Nano/Uno/Mega

Steve,

First, the MFRC Ethernet sketch should work via serial only too, even without the shield attached. Like you said, the goal is to offer a Swiss Army Knife approach to these things for users. I can likely add the blinking and 'reader connected' messages to the MFRC522 sketch. Also, the following is an Ethernet/Serial version of the PN532 sketch.?

// Include Libraries
#include <SPI.h>
#include <Adafruit_PN532.h>
#include <string.h>
#include <Ethernet.h>
?
// Ethernet configuration
byte mac[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED};
IPAddress ip(192, 168, 1, 177);
unsigned int serverPort = 8888; // Replace with the desired port number
EthernetServer server(serverPort); // Start the Ethernet server
?
struct RFIDReader {
? char id;
? uint8_t ssPin;
? Adafruit_PN532 pn532;
? byte nuid[7];
? bool cardRead;
?
? RFIDReader() : id(0), ssPin(0), pn532(Adafruit_PN532(0, &SPI)), cardRead(false) {}
};
?
#if defined(ARDUINO_AVR_UNO) || defined(ARDUINO_AVR_NANO)
const uint8_t ssPins[] = {9, 8, 7, 6, 5, A0};
const char readerID[] = {'A', 'B', 'C', 'D', 'E', 'F'};
#elif defined(ARDUINO_AVR_MEGA2560)
const uint8_t ssPins[] = {53, 52, 51, 50, 49, 48, 47, 46};
const char readerID[] = {'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H'};
#endif
?
const int numReaders = sizeof(ssPins) / sizeof(ssPins[0]);
RFIDReader readers[numReaders];
?
void setup() {
? Serial.begin(9600);
? SPI.begin();
? Ethernet.begin(mac, ip); // Initialize the Ethernet
? server.begin(); // Start the Ethernet server
?
? for (uint8_t i = 0; i < numReaders; i++) {
? ? readers[i].ssPin = ssPins[i];
? ? readers[i].id = readerID[i];
? ? readers[i].cardRead = false;
? ? readers[i].pn532 = Adafruit_PN532(ssPins[i], &SPI);
? ? readers[i].pn532.begin();
?
? ? if (readers[i].pn532.getFirmwareVersion()) {
? ? ? readers[i].pn532.SAMConfig();
? ? ? // Print information about the detected reader
? ? ? Serial.print("Reader ");
? ? ? Serial.print(readers[i].id);
? ? ? Serial.print(" detected on SS pin: ");
? ? ? Serial.println(readers[i].ssPin);
? ? } else {
? ? ? readers[i].ssPin = 0; // Mark as not detected
? ? }
? }
?
? pinMode(LED_BUILTIN, OUTPUT);
?
? // Count the number of detected readers
? uint8_t detectedReaders = 0;
? for (uint8_t i = 0; i < numReaders; i++) {
? ? if (readers[i].ssPin != 0) {
? ? ? detectedReaders++;
? ? }
? }
?
? // Blink the on-board LED based on the number of detected readers
? for (uint8_t i = 0; i < detectedReaders; i++) {
? ? digitalWrite(LED_BUILTIN, HIGH);
? ? delay(200);
? ? digitalWrite(LED_BUILTIN, LOW);
? ? if (i < detectedReaders - 1) {
? ? ? delay(200);
? ? }
? }
}
?
void loop() {
? EthernetClient client = server.available(); // Check if there's a client connected
?
? for (uint8_t i = 0; i < numReaders; i++) {
? ? if (readers[i].ssPin == 0) {
? ? ? continue;
? ? }
?
? ? uint8_t uid[] = {0, 0, 0, 0, 0, 0, 0};
? ? uint8_t uidLength;
? ? uint8_t success = readers[i].pn532.readPassiveTargetID(PN532_MIFARE_ISO14443A, uid, &uidLength);
?
? ? if (success) {
?
? ? ? memcpy(readers[i].nuid, uid, 7);
? ? ? readers[i].cardRead = true;
?
? ? ? byte checksum = readers[i].nuid[0];
? ? ? for (byte j = 1; j < 5; j++) {
? ? ? ? checksum ^= readers[i].nuid[j];
? ? ? }
?
? ? ? // Send output to Serial connection
? ? ? Serial.write(readers[i].id);
?
? ? ? // Send output to Ethernet client
? ? ? if (client) {
? ? ? ? client.write(readers[i].id);
? ? ? }
?
? ? ? for (byte j = 0; j < 5; j++) {
? ? ? ? // Send output to Serial connection
? ? ? ? Serial.print(readers[i].nuid[j] < 0x10 ? "0" : "");
? ? ? ? Serial.print(readers[i].nuid[j], HEX);
?
? ? ? ? // Send output to Ethernet client
? ? ? ? if (client) {
? ? ? ? ? client.print(readers[i].nuid[j] < 0x10 ? "0" : "");
? ? ? ? ? client.print(readers[i].nuid[j], HEX);
? ? ? ? }
? ? ? }
?
? ? ? // Send output to Serial connection
? ? ? Serial.print(checksum < 0x10 ? "0" : "");
? ? ? Serial.print(checksum, HEX);
?
? ? ? // Send output to Ethernet client
? ? ? if (client) {
? ? ? ? client.print(checksum < 0x10 ? "0" : "");
? ? ? ? client.print(checksum, HEX);
? ? ? }
?
? ? ? // Send output to Serial connection
? ? ? Serial.write(0x0D);
? ? ? Serial.write(0x0A);
? ? ? Serial.write('>');
?
? ? ? // Send output to Ethernet client
? ? ? if (client) {
? ? ? ? client.write(0x0D); // CR
? ? ? ? client.write(0x0A); // LF
? ? ? ? client.write('>');? // ETX replaced by '>'
? ? ? }
?
? ? ? delay(500); // Add a delay to avoid multiple reads
? ? } else {
? ? ? readers[i].cardRead = false;
? ? }
? }
}


Tom


Locked Re: RFID Connectivity #rfid

 

Tom,

As you say, we have a number of working sketches now. I think there are still a few tweaks to do though. I like whatt you did with the PN532 sketch where it flashes the led for the number of readers and lists which ones are connected to which pins. That would be quite nice to have on the MFRC sketches too. Currently, the PN532 sketch is Serial only. I think it would be good to have an ethernet version too.

So far, I've really only tested one reader with an Uno for these sketches. We need to test them on Nano's and Mega's to be sure. I also need to test multiple readers once the hardware has arrived. Then we can see what issues, if any, we get with 8 readers into a Mega. We might have to use a multiplexer and this would need to be added into some of the sketches.?

Once we've done that, I guess it's time to look at an easy pcb board for connections. I quite liked the idea of a Nano plugging into some headers on the pcb. I see you can get an Ethernet Shield for a Nano too? think it would also be useful to make provision for connections to Uno's and Mega's.

What are your thoughts?

Steve


Locked Re: RFID Connectivity #rfid

 

Ethernet and WiFi

Tom,

I'll post the exact working Ethernet sketch when I get home from work. I also want to see if it will work without the Ethernet Shield attached. If it does, then we don't need an Ethernet and Serial? sketch.

I'll have a go at changing pins around on the WeMos and see what happens.

Steve