YESSS!
Once I got all of the cockroaches stomped, I can get nrf24-conncheck.spin2 to function on both KISS boards! Now to finish copying over all of the files that I added to the library to the new library, I can continue on with the development of my project. Thanks for your patience with me and pointing out the possible solution with downloading the new library.
Jim
woohoo, great news! No problem, anytime.
In the future, I'd recommend downloading the repositories using git, and anytime you want to update them, all you'd have to do is git pull - this will then only download what's changed since the last time you ran it.
A second separate copy of any repositories you want to modify is a good idea, too (there are ways to manage making changes to it within git like forking a repo, or just creating another branch, but the second copy method is easier if you don't care to learn git to that depth).
OK,
back to the first problem.
direct from screenshot
"Serial terminal started
NRF24L01+ driver failed to start - halting
"
This is the TX-DEMO file, with the con info changed to match the hardware. Changed to the same as the nrfcom check which worked and reported $E7,E7...etc.
I did notice that there is no preset for TX or RX 4M?
Right now I have to reboot the computer as I am getting Checksum errors of all attempts to compile and run on P2 from flexprop.
addit: reboot solved checksum error proplem. What am I missing? Why on the same piece of hardware, same hookup do we go from displaying the contents of the rcv addr register to a load error? Is it something in the wireless file. by the way, it does not matter if I use older version or not, the problem is still the same.
Jim
The nRF24 has a max transmit/receive speed of 2Mbps, so there should be no 4Mbps preset.
The following preset methods should be available in the driver:
As for the demo startup issue:
Are the pin CONstants defined exactly the same way as they were in the connectivity check?
Have you retried the connectivity check since having difficulties with the TX Demo to verify it still works?
Have you modified the stock TX Demo to define (and power) the VCC and GND pins as in the working version of the connectivity check? I don't have that defined in any of the demos in the repository because I generally power modules using the power rails, not the I/O pins themselves.
Attached is a copy I just modified to include the VCC and GND pins that works here, with the module connected just as you have it connected to the KISS board.
Hi Jessie,
You finally made me think about the error of my ways! My last problem had to do with the use of VARs where I should have been using CONs. I think that I slipped into the VARs because I forgot that the compiler is a single pass compiler and I had gotten pin assignments out of order. Next regarding the the use of IO pins for VDD and VSS, I abandoned that effort after you mentioned the current draw potential for the NRF. They are now connected to the power rails. Once I remembered single pass and reordered pin assignment in the CON section, my problems magically went away. I think that my fail to start came from using _pin as a VAR in one place and the software uses a constant elsewhere and they did not match. Lesson learned the hardway!
Glad you're back in business... sometimes it seems learning something the hard way is the best way (rhetorical question: ask me how I know )
The non-amplified modules are probably fine to power directly from I/O pins - the catch being only the ones with genuine Nordic chips on them would be guaranteed to consume a safe amount of current. I don't know that I ever measured the draw of a fake one for myself; I just remember reading that their current draw could be higher than the real ones in certain situations.
I can certainly understand the appeal of powering it with I/O pins though - it just plugs right into the KISS board...
Jessie,
Back to having NRF start up issues. had most of the cockroaches stomped in the TX mode and switched to RX mode. Using (what I think is the same code) to start the NRF works in the TX mode and fails to start NRF in the RX mode. Still attempting to trace my steps, stay tuned. Test routine works and can run TX mode on same processor with out issue, so hardware is OK.
Jim
jessie,
OK, finally resolved startup issues by creating a whole new file and copying working code piece by piece from the old non working file and known working files. Still don't know what caused the problem, but it is resolved and I won't look back. One issue that remains, other than I am still not communicating between my P2's, is in your transmit demo, you start the transmit process by assuming failure and only transmit the new data after you have done all of the re-transmit stuff. I want to transmit the data first and do the re-transmit stuff only if there is a transmit failure, typically caused by getting close to the edge of the range. how do you suggest that I code that? I think that the RX demo will respond to what ever it gets and auto ak as ok when it gets the packet correct the first time. If I remember, I cut the auto ak out of my P1 code all together.
Thanks for all the help you have given me with the wireless, I could have not gotten this far without it.
Jim
You should be able to transmit first. The pertinent part of the loop would be changed to:
repeat
tmp := int.deczeroed(payld_cnt++, 4) ' Tack a counter onto the
bytemove(@_payload[4], tmp, 4) ' end of the payload
nrf24.txpayload(_payld_len, @_payload)
' Collect some packet statistics
max_retrans := nrf24.maxretransreached()
pkts_retrans := nrf24.packetsretransmitted()
lost_pkts := nrf24.lostpackets()
if max_retrans == TRUE ' Max retransmissions reached?
nrf24.intclear(%001) ' If yes, clear the int
if lost_pkts >= 15 ' Packets lost exceeds 15?
nrf24.channel(CHANNEL) ' If yes, clear the int
Note this is with all of the serial display code removed - it retains the packet counter at the beginning, and keeps the interrupt clearing code, but at the end of the loop now.
Are you not able to communicate between the two boards even with the stock TX and RX demos? I recommend establishing that these work solidly before going further. As I've been typing this, I've been running a pair on the bench just to make sure things still work and I didn't leave the code in an unworkable state, and it seems to be operating so far.
As long as auto-ack hasn't been disabled, the TX chip will automatically re-transmit if it doesn't get an ack from the RX, up to AutoRetransmitCount() times (can be a max of 15, default is 3).
The delay between retransmits is set with AutoRetransmitDelay() (defaults to 250uS). There are some restrictions on payload length with some combinations of DataRate() and AutoRetransmitDelay() settings (there's a table in the method that shows the max length allowed). I wouldn't recommend changing settings like these until reliable communication is established in testing, though. These would just throw extra variables into an already unknown mix.
Are your two radios fairly close for the purposes of testing (if they can be close, that's one less variable to worry about)? Just trying to get an idea of the setup.
When you said later in your post that you cut the auto-ack code out of your P1 code, did you mean this is your code as-is now, or was this something older? The retransmit functionality only works with it enabled.
Also, take care that all of the settings on the TX side and RX side match - there're obvious ones like Channel() and TXAddr()/RXAddr(), but even things like PayloadLen() must match, or else you won't receive any data. Shockburst/Auto-Ack is another one.
Jessie,
I patched your latest code into the transmit demo and it compiles and flashes ok, Right now I can't get the RX demo to load, I keep getting a load error -1 can' get checksum. I will attempt to attach the two files here.
Check them out and tell me the error of my ways.
Thanks,
JIm
I haven't yet checked the TX demo, and I don't get the same error as you loading the RX demo, however, I do get a 0 byte binary and a warning that the end of file is inside a comment - it's because all of the code is actually commented out. There's an unmatched/unclosed multi-line comment before the SER_RX constant:
{ SER_RX = cfg#SER_RX
SER_TX = cfg#SER_TX
'<--- should be a closing curly-brace here
OBJ
ser : "com.serial.terminal.ansi"
cfg : "core.con.boardcfg.KISS0001"
nrf24 : "wireless.transceiver.nrf24l01.spi"
VAR
byte _payload[32]
byte _payld_len
byte _addr[5]
CHANNEL = 113 ' 0..125
' --
.
.
.
Try adding the curly brace as noted above in the excerpt, and see if it works for you then.
EDIT:
After adding that here, it also complained because you have a constant in the VAR section (CHANNEL).
Whoops, also the duplicate OBJ and VAR definitions.
Lastly, if you have my latest nRF driver, the Start() method had been renamed to Startx() awhile back, so it'll complain about that, too.
Jessie,
I made the patch and corrected the { issue and finally got things moving. NRF communicating with NRF . Next step is to patch the working code into my program to get things running.
Jim
@avsa242
Jessie, I hate to revive this long ago thread, but after almost a year, I have lots of time to work on this again(Covid).
I was trying to do some troubleshooting and I set up this basic piece of code to do it:
HM
idx :=0
repeat idx from 0 to 100
ser.Position(0, idx)
ser.printf(" how now brown cow idx = ")
ser.dec(idx)
idx++
Now the results I get from the terminal are as follows:
1f[1;1f how now brown cow idx = 0[3;1f how now brown cow idx = 2[5;1f how...
as you can see, it is printing out the escape sequences rather than preforming the necessary positioning.
Now this is using the com.serial.terminal.ansi.spin2 file from this discussion. For some reason, the position(x;y) command is not being executed as expected. I was hoping that I could use that feature to be able to study the results of my testing. My other issue is a serial baud issue that I have to track down, seems my terminal mode does not like 2megabaud. I don't know if it is a board issue or a computer issue.
As a reminder, I am using Linux Mint 20 on a HP G6 laptop.
No problem - anytime.
What terminal app are you using this with on the PC? The com.serial.terminal.ansi.spin(2) object expects you're using a terminal that can parse ansi-compatible cursor positioning escape codes (Propeller Tool's serial terminal isn't one of these).
Also about when is your copy of the serial object from? For the past few months I've been working at improving the consistency among all of my repos, including the spin1 and spin2 libraries. I've been doing these in new branches (api_changes), so the default testing branch shouldn't be affected, but I could've mistakenly slipped in a change before realizing I was still in the testing branch.
Also, in case you are using an ANSI-compatible terminal, are you willing to share an archive of the complete project or test code you're using? It'd be easier for me to help if I can run the exact same code you are.
Just tried it in flexprop's built-in terminal and while most of the attributes don't seem to be implemented, the escape codes don't "leak through", and positioning does work.
Also a side note: I just noticed in your code example above you use printf() to output a string, then on the following line a dec() to output a number. This is technically OK, but printf() is meant to provide the means to add things like variables to the output so you don't have to do discrete statements like that.
So this:
ser.printf(" how now brown cow idx = ")
ser.dec(idx)
would become something like this, instead:
ser.printf(" how now brown cow idx = %d", idx)
printf() then replaces %d with the corresponding parameter (the variable idx in this case)
Okay - the next step then would be to ensure it is set to ANSI terminal, not PST terminal.
As in:
I think this may be your issue. I just tried switching it to PST terminal on a hunch and I got the escape codes printed to the terminal as in your original post.
OK
I tried the printf format suggestion, that works beautifully. I still do not have Position(x,Y) working. Next question are the NRF modules 5 volt tolerant as far as VDD is concerned? I was sitting here gazing at a photo I have of the module and it shows a VDD of 3.3V and I at some point connected both my transmitter and my receiver to 5 v. I just rewired the boards to 3.3 and now I am getting a failure to start from the rewired one.
Edit: am running the latest version of flexprop I just downloaded and installed yesterday.
Jim
That probably depends on the mfr of the modules themselves. Some manufacturers of modules/breakout boards for radios like these or sensors, etc, design them with a voltage regulator onboard so either voltage can be used. You'd have to check the ones you're using.
The chip itself has 5v-tolerant inputs, but the supply (Vdd) maxes out at 3.6v (and that's an absolute max, not a typical value).
OK, my boards are ITED and I guess that I have fried them! I have one still new in the package but I think I have destroyed the other 3. Is there somewhere stateside I can order new ones for a reasonable price, or do I have to go off shore?
Jim
They're a little more than the ITEAD ones, but still cheap ($4.95). No idea if they're going to be genuine chips (they don't cite so specifically, that I can see), but they do say they test samples of them when they get them.
EDIT:
They also sell an adaptor that has a regulator on it, so it could be safely used with 5v ($0.95). Also the non-amplified ones for $1.69
Jessie,
I found the problem that I was having with my serial test module. There is a bug in the latest version of flexprop! I went back and copied the program into a previous version of flexprop and the ansi terminal formatting works correctly.
Edit: can I assume that you are using V 5.19.19? I had upgraded to 5.19.20 when the baud and formatting issues came up.
Jim
@avsa242
jessie,
after much discussion with @ersmith, I went in and modified my flexprop so that I was using an external terminal and that works fine with the data formatting. I have made a slight revision to my test code to do a continous repeat and printing a different value each loop with idx:
` HM
ser.clear
i:=0
repeat
repeat idx from 0 to 10
i:= i+idx
ser.position (0, idx)
Ser.printf("how now brown cow, idx = %d", i)
pause(1000)
i++
After fixing some coding screw ups, it works as it should. I guess from now on I have to use the external terminal whenever I want formatted data.
Now, I can get back to coding the program I walked away from a year ago.
Jim
@RS_Jim said:
@avsa242
jessie,
after much discussion with @ersmith, I went in and modified my flexprop so that I was using an external terminal and that works fine with the data formatting. I have made a slight revision to my test code to do a continous repeat and printing a different value each loop with idx:
` HM
ser.clear
i:=0
repeat
repeat idx from 0 to 10
i:= i+idx
ser.position (0, idx)
Ser.printf("how now brown cow, idx = %d", i)
pause(1000)
i++
After fixing some coding screw ups, it works as it should. I guess from now on I have to use the external terminal whenever I want formatted data.
Now, I can get back to coding the program I walked away from a year ago.
Jim
hmmm ok 🤔 interesting
If I have some spare time soon I'll see if I can reproduce this (I always use konsole as a terminal so I wouldn't have run into it before).
Jessie,
I got the NRF modules from Photosupplies and I think they are the real thing. I also got the base module so that I would not have a problem with power trashing the modules. But alas No Bueno, not communicating. Some time ago, you sent me a file that checked the connections to the NRF and read back the device address. I run that and it reports E7E7... etc. So it appears that I am communicating with the device just not getting data thru the link. The version of the wireless transceiver is dated June 27, 2021. Is that the latest and greatest? I am at my wits end. Maybe I should take up knitting or macrame.
Jim
No, I recently updated it - the latest is always on github. Note that the api has changed quite a bit since then. I've tried to rewrite all of my wireless as well as other types of drivers to operate as much the same way as possible so I could switch one in place of another without a great deal of rewriting applications.
As far as getting it to work, have patience. I'd always recommend starting off with something known working, and changing as little as possible, if anything. Change one thing at a time to suit your app. As packet radios go, the nrf24 is on the simpler side, but it's still easy to get screwed up. Only one setting has to be mismatched between the TX and RX for them not to communicate.
Just a couple of weeks ago I tested out the receive and transmit demos together and they worked. I'd download the current p2-spin-standard-library and try the nrf24 demos in there. Chances are some of it will break existing code you've written so I'd suggest downloading it in a separate place rather than overwriting your current copy.
Comments
YESSS!
Once I got all of the cockroaches stomped, I can get nrf24-conncheck.spin2 to function on both KISS boards! Now to finish copying over all of the files that I added to the library to the new library, I can continue on with the development of my project. Thanks for your patience with me and pointing out the possible solution with downloading the new library.
Jim
woohoo, great news! No problem, anytime.
In the future, I'd recommend downloading the repositories using git, and anytime you want to update them, all you'd have to do is
git pull- this will then only download what's changed since the last time you ran it.A second separate copy of any repositories you want to modify is a good idea, too (there are ways to manage making changes to it within git like forking a repo, or just creating another branch, but the second copy method is easier if you don't care to learn git to that depth).
Cheers
OK,
back to the first problem.
direct from screenshot
"Serial terminal started
NRF24L01+ driver failed to start - halting
"
This is the TX-DEMO file, with the con info changed to match the hardware. Changed to the same as the nrfcom check which worked and reported $E7,E7...etc.
I did notice that there is no preset for TX or RX 4M?
Right now I have to reboot the computer as I am getting Checksum errors of all attempts to compile and run on P2 from flexprop.
addit: reboot solved checksum error proplem. What am I missing? Why on the same piece of hardware, same hookup do we go from displaying the contents of the rcv addr register to a load error? Is it something in the wireless file. by the way, it does not matter if I use older version or not, the problem is still the same.
Jim
Jim,
The nRF24 has a max transmit/receive speed of 2Mbps, so there should be no 4Mbps preset.
The following preset methods should be available in the driver:
As for the demo startup issue:
Are the pin CONstants defined exactly the same way as they were in the connectivity check?
Have you retried the connectivity check since having difficulties with the TX Demo to verify it still works?
Have you modified the stock TX Demo to define (and power) the VCC and GND pins as in the working version of the connectivity check? I don't have that defined in any of the demos in the repository because I generally power modules using the power rails, not the I/O pins themselves.
Attached is a copy I just modified to include the VCC and GND pins that works here, with the module connected just as you have it connected to the KISS board.
Hi Jessie,
You finally made me think about the error of my ways! My last problem had to do with the use of VARs where I should have been using CONs. I think that I slipped into the VARs because I forgot that the compiler is a single pass compiler and I had gotten pin assignments out of order. Next regarding the the use of IO pins for VDD and VSS, I abandoned that effort after you mentioned the current draw potential for the NRF. They are now connected to the power rails. Once I remembered single pass and reordered pin assignment in the CON section, my problems magically went away. I think that my fail to start came from using _pin as a VAR in one place and the software uses a constant elsewhere and they did not match. Lesson learned the hardway!
Hi Jim,
Glad you're back in business... sometimes it seems learning something the hard way is the best way (rhetorical question: ask me how I know
)
The non-amplified modules are probably fine to power directly from I/O pins - the catch being only the ones with genuine Nordic chips on them would be guaranteed to consume a safe amount of current. I don't know that I ever measured the draw of a fake one for myself; I just remember reading that their current draw could be higher than the real ones in certain situations.
I can certainly understand the appeal of powering it with I/O pins though - it just plugs right into the KISS board...
Having issues again need to bring this back to top for reference.
jim
Hi Jim, what's happening?
Jessie,
Back to having NRF start up issues. had most of the cockroaches stomped in the TX mode and switched to RX mode. Using (what I think is the same code) to start the NRF works in the TX mode and fails to start NRF in the RX mode. Still attempting to trace my steps, stay tuned. Test routine works and can run TX mode on same processor with out issue, so hardware is OK.
Jim
jessie,
OK, finally resolved startup issues by creating a whole new file and copying working code piece by piece from the old non working file and known working files. Still don't know what caused the problem, but it is resolved and I won't look back. One issue that remains, other than I am still not communicating between my P2's, is in your transmit demo, you start the transmit process by assuming failure and only transmit the new data after you have done all of the re-transmit stuff. I want to transmit the data first and do the re-transmit stuff only if there is a transmit failure, typically caused by getting close to the edge of the range. how do you suggest that I code that? I think that the RX demo will respond to what ever it gets and auto ak as ok when it gets the packet correct the first time. If I remember, I cut the auto ak out of my P1 code all together.
Thanks for all the help you have given me with the wireless, I could have not gotten this far without it.
Jim
Jim,
You should be able to transmit first. The pertinent part of the loop would be changed to:
repeat tmp := int.deczeroed(payld_cnt++, 4) ' Tack a counter onto the bytemove(@_payload[4], tmp, 4) ' end of the payload nrf24.txpayload(_payld_len, @_payload) ' Collect some packet statistics max_retrans := nrf24.maxretransreached() pkts_retrans := nrf24.packetsretransmitted() lost_pkts := nrf24.lostpackets() if max_retrans == TRUE ' Max retransmissions reached? nrf24.intclear(%001) ' If yes, clear the int if lost_pkts >= 15 ' Packets lost exceeds 15? nrf24.channel(CHANNEL) ' If yes, clear the intNote this is with all of the serial display code removed - it retains the packet counter at the beginning, and keeps the interrupt clearing code, but at the end of the loop now.
Are you not able to communicate between the two boards even with the stock TX and RX demos? I recommend establishing that these work solidly before going further. As I've been typing this, I've been running a pair on the bench just to make sure things still work and I didn't leave the code in an unworkable state, and it seems to be operating so far.
As long as auto-ack hasn't been disabled, the TX chip will automatically re-transmit if it doesn't get an ack from the RX, up to AutoRetransmitCount() times (can be a max of 15, default is 3).
The delay between retransmits is set with AutoRetransmitDelay() (defaults to 250uS). There are some restrictions on payload length with some combinations of DataRate() and AutoRetransmitDelay() settings (there's a table in the method that shows the max length allowed). I wouldn't recommend changing settings like these until reliable communication is established in testing, though. These would just throw extra variables into an already unknown mix.
Are your two radios fairly close for the purposes of testing (if they can be close, that's one less variable to worry about)? Just trying to get an idea of the setup.
When you said later in your post that you cut the auto-ack code out of your P1 code, did you mean this is your code as-is now, or was this something older? The retransmit functionality only works with it enabled.
Also, take care that all of the settings on the TX side and RX side match - there're obvious ones like Channel() and TXAddr()/RXAddr(), but even things like PayloadLen() must match, or else you won't receive any data. Shockburst/Auto-Ack is another one.
Cheers
Jesse
Jessie,
I patched your latest code into the transmit demo and it compiles and flashes ok, Right now I can't get the RX demo to load, I keep getting a load error -1 can' get checksum. I will attempt to attach the two files here.
Check them out and tell me the error of my ways.
Thanks,
JIm
Jim,
I haven't yet checked the TX demo, and I don't get the same error as you loading the RX demo, however, I do get a 0 byte binary and a warning that the end of file is inside a comment - it's because all of the code is actually commented out. There's an unmatched/unclosed multi-line comment before the SER_RX constant:
{ SER_RX = cfg#SER_RX SER_TX = cfg#SER_TX '<--- should be a closing curly-brace here OBJ ser : "com.serial.terminal.ansi" cfg : "core.con.boardcfg.KISS0001" nrf24 : "wireless.transceiver.nrf24l01.spi" VAR byte _payload[32] byte _payld_len byte _addr[5] CHANNEL = 113 ' 0..125 ' -- . . .Try adding the curly brace as noted above in the excerpt, and see if it works for you then.
EDIT:
After adding that here, it also complained because you have a constant in the VAR section (CHANNEL).
Whoops, also the duplicate OBJ and VAR definitions.
Lastly, if you have my latest nRF driver, the Start() method had been renamed to Startx() awhile back, so it'll complain about that, too.
Cheers
Jessie,
I made the patch and corrected the { issue and finally got things moving. NRF communicating with NRF . Next step is to patch the working code into my program to get things running.
Jim
@avsa242
Jessie, I hate to revive this long ago thread, but after almost a year, I have lots of time to work on this again(Covid).
I was trying to do some troubleshooting and I set up this basic piece of code to do it:
HM
idx :=0
repeat idx from 0 to 100
ser.Position(0, idx)
ser.printf(" how now brown cow idx = ")
ser.dec(idx)
idx++
Now the results I get from the terminal are as follows:
1f[1;1f how now brown cow idx = 0[3;1f how now brown cow idx = 2[5;1f how...
as you can see, it is printing out the escape sequences rather than preforming the necessary positioning.
Now this is using the com.serial.terminal.ansi.spin2 file from this discussion. For some reason, the position(x;y) command is not being executed as expected. I was hoping that I could use that feature to be able to study the results of my testing. My other issue is a serial baud issue that I have to track down, seems my terminal mode does not like 2megabaud. I don't know if it is a board issue or a computer issue.
As a reminder, I am using Linux Mint 20 on a HP G6 laptop.
Any thoughts would be appriciated.
Jim
Hi Jim,
No problem - anytime.
What terminal app are you using this with on the PC? The com.serial.terminal.ansi.spin(2) object expects you're using a terminal that can parse ansi-compatible cursor positioning escape codes (Propeller Tool's serial terminal isn't one of these).
Also about when is your copy of the serial object from? For the past few months I've been working at improving the consistency among all of my repos, including the spin1 and spin2 libraries. I've been doing these in new branches (
api_changes), so the defaulttestingbranch shouldn't be affected, but I could've mistakenly slipped in a change before realizing I was still in thetestingbranch.Also, in case you are using an ANSI-compatible terminal, are you willing to share an archive of the complete project or test code you're using? It'd be easier for me to help if I can run the exact same code you are.
Cheers,
Jesse
Just tried it in flexprop's built-in terminal and while most of the attributes don't seem to be implemented, the escape codes don't "leak through", and positioning does work.
Also a side note: I just noticed in your code example above you use
printf()to output a string, then on the following line adec()to output a number. This is technically OK, butprintf()is meant to provide the means to add things like variables to the output so you don't have to do discrete statements like that.So this:
ser.printf(" how now brown cow idx = ") ser.dec(idx)would become something like this, instead:
ser.printf(" how now brown cow idx = %d", idx)printf()then replaces%dwith the corresponding parameter (the variable idx in this case)Hi Jessie,
Thanks for the quick reply. My terminal is the one in flexprop. I will try the printf as you suggested and get back shortly.
Jim
Jim,
Okay - the next step then would be to ensure it is set to ANSI terminal, not PST terminal.
As in:
I think this may be your issue. I just tried switching it to PST terminal on a hunch and I got the escape codes printed to the terminal as in your original post.
OK
I tried the printf format suggestion, that works beautifully. I still do not have Position(x,Y) working. Next question are the NRF modules 5 volt tolerant as far as VDD is concerned? I was sitting here gazing at a photo I have of the module and it shows a VDD of 3.3V and I at some point connected both my transmitter and my receiver to 5 v. I just rewired the boards to 3.3 and now I am getting a failure to start from the rewired one.
Edit: am running the latest version of flexprop I just downloaded and installed yesterday.
Jim
Jim,
That probably depends on the mfr of the modules themselves. Some manufacturers of modules/breakout boards for radios like these or sensors, etc, design them with a voltage regulator onboard so either voltage can be used. You'd have to check the ones you're using.
The chip itself has 5v-tolerant inputs, but the supply (Vdd) maxes out at 3.6v (and that's an absolute max, not a typical value).
OK, my boards are ITED and I guess that I have fried them! I have one still new in the package but I think I have destroyed the other 3. Is there somewhere stateside I can order new ones for a reasonable price, or do I have to go off shore?
Jim
Jim,
I found these:
https://protosupplies.com/product/nrf24l01palna-2-4ghz-rf-wireless-module/
They're a little more than the ITEAD ones, but still cheap ($4.95). No idea if they're going to be genuine chips (they don't cite so specifically, that I can see), but they do say they test samples of them when they get them.
EDIT:
They also sell an adaptor that has a regulator on it, so it could be safely used with 5v ($0.95). Also the non-amplified ones for $1.69
I Like the fact that they have the LNA and antenna, I think that I will order 2.
Thanks
Jim
Jessie,
I found the problem that I was having with my serial test module. There is a bug in the latest version of flexprop! I went back and copied the program into a previous version of flexprop and the ansi terminal formatting works correctly.
Edit: can I assume that you are using V 5.19.19? I had upgraded to 5.19.20 when the baud and formatting issues came up.
Jim
@avsa242
jessie,
after much discussion with @ersmith, I went in and modified my flexprop so that I was using an external terminal and that works fine with the data formatting. I have made a slight revision to my test code to do a continous repeat and printing a different value each loop with idx:
` HM
ser.clear
i:=0
repeat
repeat idx from 0 to 10 i:= i+idx ser.position (0, idx) Ser.printf("how now brown cow, idx = %d", i) pause(1000) i++After fixing some coding screw ups, it works as it should. I guess from now on I have to use the external terminal whenever I want formatted data.
Now, I can get back to coding the program I walked away from a year ago.
Jim
hmmm ok 🤔 interesting
If I have some spare time soon I'll see if I can reproduce this (I always use konsole as a terminal so I wouldn't have run into it before).
Jessie,
I got the NRF modules from Photosupplies and I think they are the real thing. I also got the base module so that I would not have a problem with power trashing the modules. But alas No Bueno, not communicating. Some time ago, you sent me a file that checked the connections to the NRF and read back the device address. I run that and it reports E7E7... etc. So it appears that I am communicating with the device just not getting data thru the link. The version of the wireless transceiver is dated June 27, 2021. Is that the latest and greatest? I am at my wits end. Maybe I should take up knitting or macrame.
Jim
Jim,
No, I recently updated it - the latest is always on github. Note that the api has changed quite a bit since then. I've tried to rewrite all of my wireless as well as other types of drivers to operate as much the same way as possible so I could switch one in place of another without a great deal of rewriting applications.
As far as getting it to work, have patience. I'd always recommend starting off with something known working, and changing as little as possible, if anything. Change one thing at a time to suit your app. As packet radios go, the nrf24 is on the simpler side, but it's still easy to get screwed up. Only one setting has to be mismatched between the TX and RX for them not to communicate.
Just a couple of weeks ago I tested out the receive and transmit demos together and they worked. I'd download the current p2-spin-standard-library and try the nrf24 demos in there. Chances are some of it will break existing code you've written so I'd suggest downloading it in a separate place rather than overwriting your current copy.
Ok, Will do. refresh my memory as how to get it all in one pass.
Thanks.
Jim