#help-with-radio
1 messages · Page 10 of 1
Yeah, that's a little bit beyond me..
That means 'blink the LED as fast as possible' on a SAMD51 board. ;)
Alrighty
OUTTGL is a toggle.
1 << 23 means to set the 2^23 bit in a 32-bit register (uint32_t).
0000 0000 1000 0000 0000 0000 0000 0000
that's what it means. ;)
I always get them mixed up so check if there's betting money involved. ;)
PORT ->Group[0] refers to PA23 (the LED) which is on PORT A.
(the 0 there for 'Group[0]is theAof PORTA`.
I decoded it, I didn't author it (at all).
Haven't looked at any documentation at all, either. ;)
I'm going to assume that you are a computer engineer then 😃
Ah
It was so much easier to just try something and run it on the hardware, than to look it up anywhere in a structured way.
It if smokes, that's 30 bux. No big crisis (until it's the third one this week, that is. ;)
As it turns out, that strange code turns the port pin designated as D13 (in Arduino-speak) ON (only if it was presently OFF) and it also turns it OFF (if it was already ON).
I knew it was an OUTPUT so OUTTGL makes sense as 'output toggle'.
Ah, good catch
I'm guessing the documentation (datasheet) would say 'OUTPUT TOGGLE REGISTER'.
My method is obtuse (to say the least) but by the time I have working (explained, or somewhat explained) code I've looked at so much unrelated stuff, that I have a good working knowledge of an entire subsystem (whether I wanted that or not, I now have it as a side-effect of my approach to 'learning').
Not a bad way to learn.
I really like the Silabs datasheets for 8051 and really do not like our SAMD51 datasheet.
What about it do you not like?
It's visual, what I do and do not like about it.
Above is my favorite datasheet for a microcontroller.
On the 'splash' page it tells you all the good news about using C8051F330.
Indeed!
You can do a lot in 768 bytes of RAM.
I love how they call it a datasheet, when it really is more of a full length novel 😛
8 kb flashROM is roomy
right .. yeah chapter 31 . it's like going to the movies on a Saturday to get the next installment.
for the rest of your life. ;)
I have a working C2 (two wire) implementation for the C8051F330 .. it's like JTAG sort of.
Also a serial bootloader..
Nice!
C2 is probably closer to the SWD interface for SAMD21.
Well the nice thing is I can swap the chips .. I use the F330 to talk to another F330 via the C2 interface.
(I didn't write any of the original or think any of it out; I ported existing work to F330 simply because it was the one chip Silabs had in that product family in a DIP20 package.)
I think the port came from either F300 or F310 (same product family).
So every chip I acquire has the bootloader on it and can be used to educate a new factory chip to get a bootloader onto it for the first time. ;)
If I lose the very last of them, I have no means to get started again.
(think about that, for a minute, NASA ;)
Like going to the Moon, and forgetting the cork screw -- how are you going to open the bottle of wine?)
(because what else would you on the Moon?)
You don't have the bootloader saved anywhere else?
There's no means to get the bootloader into a chip without that program and without a chip that has that program already loaded on it.
I've had a board now for 15 years or so I can't do anything with because of this issue.
well, that is a problem
I could go the canonical route and load Windows<tm> and Keil stuff and upload someone else's work.
I could have done so 15 years ago.
That wouldn't be the same thing at all.
The whole point is to run my code on it, not something I don't understand, on it.
It's a really nice board. I think they still have them!
Nice!
C8051F120 developer's board.
I get wanting to do it all yourself.
My goal is to have an entire system I understand. All of it.
I do not think I will make it, but it's my goal. ;)
That's an awesome goal to have!
Thanks. You're very encouraging.
That's a valued trait around these parts. ;)
Might want to visit at a CircuitPython meeting (right here, on a Monday at .. oh.. 18:00 UTC).
I've listened to the recordings of a few of those.
there's no requirement .. you are free to audit anytime in realtime.
they call on you unless you ask not to be called on. ;)
I made a Raggedy Anne that blinks red evil LED eyes is a fine report to make in that meeting.
;)
Lol. Yeah we'll see 1800 UTC is right in the middle of my workday, but I might have to jump into one before the school year starts up.
Been trying to get more into Circuit Python this summer, planning to push my students to try it out more.
I think they should have a provision for pre-recorded contributions, personally. ;)
I think the learning curve on CircuitPython is pretty good. I find it helpful for hardware stuff too.
I think so too, and for the students who just don't get it, I can always nudge them to MakeCode
I was supposed to be an electronics instructor in the Air Force, but I was only 21 and nobody spoke to me about it. I got orders to do it, but no meeting to ask me to do it. So I turned down the orders. ;)
MakeCode is great because it's visual.
(when you graduate technical school, everyone gets their orders at the same time in that class; and they allow you to 'swap orders` with a classmate)
They were going to make you an instructor straight out of tech school?
Yeah I thought that was a bit much.
I was an honor grad and had 100 percentile average on every test, except a few, bringing it down to 97 percent. ;)
ah
Plus I'd been a ham seven years at the time.
Well that would help 😛
They knew I was a natural (most of my class hadn't heard of any of this stuff before they went to those classes).
I would have made a good instructor but a poor Airman, by their plans for me -- that's how I viewed it.
lol
I started teaching some stuff right after I graduated college. I now almost have the full confidence to teach college students just a few years younger than me.
I would have laughable authority on matters 'air force'. I'd be a fool. ;)
(not that I've evaded that, haha)
I also taught high school electronics ..in high school. student teacher spot.
I was (rightfully) dismissed shortly after I'd begun.
It was a bad fit (I didn't have the social presence of mind to do a good job with them, emotionally)
I said you people and it all died right then and there, in that moment.
Ah, yeah. The social interaction aspect is probably the most important part of teaching I've found. I'm technically a lab director, but I end up teaching informally or giving workshops a lot. Attitude and demeanor make a huge difference.
I didn't develop compassion (expressed compassion) on that level for decades afterward.
So it was never going to work -- timing was way wrong.
Something I'm learning as well. I tend to be a little harsher with students. I deal with mostly junior level engineering students, and expect them to know more than I guess they do. They don't like it when the only answer they can give me is "I don't know".
I love being harsh ;)
I think I would be very good at leading a student out of I don't know because I know what it feels like to have to say only that much.
It's all stage fright.
They know a lot more than they know they know. ;)
I need to practice leading them out more...
Yeah you're leading them with a lantern and it's dark outside.
You've been this way before and know there's a root you trip over, right there, so avoid it.
(then you trip on a stone next to it and we all laugh together)
Lol
I got a really good one for you. (looks it up)
This is Richard Feynman, talking about the approach he took with his lectures and where he thought he did well, and where he thought he needed to improve, and why. And about the students and what they are like to work with.
He's about as honest as Hemingway was, and that's saying quite a lot. ;)
Thanks! I'll need to listen to that.
(it's to read; there ain't no audio ;)
My bad
He's really good at this.
(but didn't know it)
In the olden days the author pretty much always opens a new book with their apology haha.
Wonder how much of that is just convention.
Oh I think the urge to apologize is endemic and to ..somehow .. not give into it is the hard part.
Nothing false about it. The expressed language forms, those are a bit staid, but the deep of it is authentic. People are really very not sure they have the right to speak on things with any authority.
It seems that there's two ways to be considered an authority or someone who can speak with authority, self declared, or declared by your peers. I could see there being an aversion to self declaring because it can smack of arrogance. To be declared an authority by your peers takes a lot longer, but can give a more solid reputation to your authority
I think everyone (pretty much or maybe 7 in 10 of everyone) should just take the chance and stand on what they know (But not on their ignorance).
The thing that floors me about what we see from Adafruit is the improbable characters who turn out to be .. pretty darned authorative. And very young, so.
I'd say 61 % of that is willingness to not be taken as authorative .. to take the risk of being undermined.
To take the risk of being wrong
Or just not all that effective. ;)
The effect upon the mind .. upon the brain physiology; chemistry .. of going a bit too far .. and having it work out quite nicely .. is such an eye opener.
It's an experience people should have.
Agreed.
oh these hakko wire strippers for wire wrap wire are really worth it.
I got my goodie bag via UPS a few minutes ago. Two scope probes in there, too. ;)
and the segger jlink EDU. ;)
Nice! It's always fun to get new toys.
Well I'm like 58 years old now and it's my time. I don't know how much older I'm going to get, so I'm getting my toys.
I've never had the chance to do wire wrap. Seen a lot of it online, but solderless breadboards and perfboard are so common these days.
too bad a 100 MHz scope probe does not make a 25 MHz scope into a 100 MHz scope ;)
I don't have any wire wrap 'posts' to wrap onto but the stuff has other uses similar to that use.
You can improvise in ways that breadboards frustrate. I use the 0.1" extra long headers extensively for this as well.
The test points work really well with 30 AWG wire. ;)
http://adafu.it/3824
So you use 0.1" Header pins as sort of wire wrap posts?
Um yeah sort of.
That's really clever! I like it!
What I do is allow adjacent pin room -- no shorts so I skip a pin.
I coil the wire by hand around the 0.1" header pin, still on its carrier with 4 others.
The turns are spaced about 5 wire diameters apart or more.
But they're tight.
Then I just shove the whole thing into the breadboard.
It just kind of squishes the loose spiral together.
Yeah, but it's a solid connection.
I'm not running into problems yet and I am dealing with < 2mA current and up to 2 MHz signal 'intensities' (data rates).
Probably closer to 750 kHz.
I'm looking for low noise low current higher data rate connections for communications (SPI, i2c, UART style SERCOMs)
The test points are working well also.
I bolt the target board (Feather M4 Express) on standoffs to perfboard, for mechanical stability.
Then I just push the bare 30 AWG up through the bottom, and pin it down with the test point (sharing the same through-plated hole as the test point).
The rest is a form of 'sewing' and 'stitching' with the 30 AWG.
That fixes it mechanically so the tenuous connection at the test point isn't disturbed by tugging on it.
I like it!
So I make sure when you pull on the bare wire (already poked through, from below) is already binding by the interweaving done to that wire in the perfboard holes.
No solder. ;)
None at all
I can't solder anymore unless I had a lab which I do not have.
I do have photos but I can't find them.
Why can't you solder? Fumes?
Ah yes, definitely not what you want.
it's too much trouble in a living situation with food safety and all that.
Agreed
there's been talk lately about a lab but I think that's pie in the sky. ;)
Not necessarily
I don't remember ever having a little grounding clip for a scope probe.
They all have them, now.
They do. I've never used one without a grounding clip.
I think we used to be okay with a separate long test lead to connect the ground.
(or maybe just float hehe I don't remember)
I always use an isolation transformer to power the scope anyway.
But the little grounding clip is proving restrictive of motion.
I think I'll get a second pair of probes just so I can be rid of the grounding clip by disconnecting at the BNC bayonnette end of things ;)
wow no double consonants at all: bayonet
(I usually add all possibles in, then subtract the ones not required) ;)
Lol, that's one way to do it. I wonder why they all do ground clips these days.
To measure higher frequency signals correctly, you need the ground clips. For low frequency (audio) stuff, it doesn't matter as much.
200 kHz and we were darned glad to have it
Says it has differential amps on the inputs.
Nicer probes have a choice of removeable ground clips.
CRT phosphors: specify by Phosphor Number (P-31 standard, P2, P7 with amber filter, P11 available, no charge).
!
@primal warren aha! we had the good probes (and lots of users handling them)
so I never even saw any clips. ;)
Removeable ground clip: for even higher frequencies, other methods are used.
@silent jolt
Mine are removeable but I don't want to remove then unremove them.
like it ruins the spring
So, two sets, one with the clips removed!
I have not yet found the chopped waveform setting on this (OWON PDS5022S 25 MHz) oscilloscope.
There are a mindbending variety of accessories available for really high frequency oscilloscoping.
Until I saw the HP manual I'd forgotten how ubiquitous the chopped setting was.
I got spoiled by dual-beam scopes, so I didn't use the chopped or alternate settings much. Then again, Jim Williams would use a pair of 4-channel plugins on a dual-beam scope to get 8 traces at once.
@primal warren is it hopeless to do anything with a 25 MHz oscilloscope in the way of verifying a 120 MHz signal is present/absent?
The scope sees it as 20 MHz.
Sometimes the frequency counter reads 48 MHz which is also possible.
(I may actually be generating 48 MHz not 120 MHz)
Depends on the scope. An analog scope rolls off at 3dB/octave above its frequency, so you can view higher frequencies, but they'll be attenuated commensurately, and their harmonics even more so (so a square wave may look like a sine wave).
However, it sounds like you're using a digital scope, so the situation is trickier.
My shortwave portable radio (AM only; aircraft band) is quite sure of itself that there is a 120 MHz signal coming from theSAMD51.
It certainly sounds like something is present, but it's hard to tell what the frequency actually is.
Yeah I agree.
I think it could be the sixth multiple of x to get to 120 (20 in this case)
20 x 6 = 120
I don't know if physics allows such 'harmonic' radiation.
Yeah, a waveform with steep rise/fall will generate a bunch of harmonics, so a 20MHz square wave will generally give a 120MHz signal too. Sounds like a job for a faster scope, a spectrum analyzer, or a frequency counter.
The code's author claims it was verified at 120 MHz.
I'm unconvinced and can't think of a computer program that can do some convincin'.
Absent all of those, I'd bodge up a divider chain out of flip-flops and monitor the divided-down output.
ah right. thanks. that's the right thing here.
I think it's a weak signal though.
May not trigger a flip flop as i think it's intentionally weak on that pin.
That's not a complete program (unless it is, by accident)
should run but I haven't tested itt. I have tested itt.
Correct program for the D.U.T.
Says 120 MHz but I don't have proof here (no fast scope or freq. counter/what-have-you).
Cooked version - has LED blinkie included.
reference board is Feather M4 Express btw. ;)
D4 seemed the best choice for putting out the oscillator on an external pin.
D11 is an arbitrary GPIO (choose any). D13 is our usual LED friend.
I didn't see a lot of signal on D4.
Tempted to try it, even though my fast scope is currently out of action. Do I need Atmel Studio to compile this?
it's an online gui configuratororor. @primal warren
I have screenshots.
https://github.com/wa1tnr/ainsuForth-d51/tree/clockey-amrt-aa-8_AUG-d-
base directory and recent branch
it's probably a mess.
The build environment is the same as for Circuit Python in that you need the ARM gcc to compile this.
https://learn.adafruit.com/building-circuitpython explains that process in some detail.
This compiler may be the whole shootin' match, not sure:
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
It's part of it (the only part I care about, probably).
To install I use the arduino version of bossac and a Makefile target for a shell script that runs bossac with the correct parameters.
(for SAMD51 the older bossac didn't work, iirc)
We're talking about programs of less than 2kb stored in a .bin file, by the way. ;)
Same program in Arduino is about 11x that.
Maybe less. Haven't done an empty Arduino compile in a while.
Looks like Arduino doesn't run the clock as fast as possible.
I've got the SAMD51 sending me five letters via the (bitbanged) UART pins (ignoring the UART itself for the moment).
I have a space for a separator, too, so that I can send small coded groups.
Basically 26 uSec for each element at 38400 bps
Every sequence begins and ends with a cleared bit (GPIO to ground).
Sandwiched in between are the bits for 2^0 through 2^6. 3.3 volts is a set bit (a 1 vs a 0 of the cleared bit).
keep the line at 3.3V when not sending anything. That's about it.
LSB goes out first.
MSB sent last.
(least and most significant bit, respectively).
So the start and stop bits are zero's.
(which differentiates them from the ongoing 'drone' of all 11111s which is just the line held indefinitely at 3.3 V level).
No event marks two adjacent bits with the same value.
Just keep the line held at that level (3.3V or 0 V).
And time it out -- use strict time intervals as the 'marker' of an event.
I would guess the listening end has to be forgiving, and make a best guess about the intent of the sender, if things are timed a bit sloppy.
It only has to pay attention for that brief moment; there's probably a minimum guard time between characters to make sure each data frame has its own reference point (with the start bit sent at any unexpected time).
This is what was typed by the SAMD51 as I wrote that, just now.
I did not plan that. I just had it recite over and over what it knew. ;)
(eh they're not taking over, just yet!)
The oscilloscope helped a lot.
2096 bytes ;) That's the size of the binary uploaded to theSAMD51.
After proving the technique on a dozen characters in the alphabet, I found an algorithmic method to take the ASCII value and pretty much send it right out the (ersatz) serial port to the PiUART.
void blitwbits(unsigned int x) {
// accepts ASCII value as input 'x'
send_preamble();
for(int i = 0; i < 7; i++) {
(x & (1u << i)) ? bit_SET() : bit_CLR();
}
common_end();
}
Preamble and common_end are nothing more than the common parts to all characters.
bit_CLR() is the essence of send_preamble().
bit_CLR() bit_SET() is the intent of common_end().
The details involve making adjustments to timing (so that things don't happen so fast that the PiUART decides it doesn't understand what's going on anymore).
What was interesting to me was the complete lack of traffic on the RX pin of the TX/RX UART pair (here used dumbly as simple GPIO pins).
As the (immediate) aim was to get messages out of the SAMD51 I wasn't interested in hearing from the PiUART (as to accept keystrokes on a command line, for example).
I think I had a hidden assumption about 'handshaking' that just didn't apply here.
On an amateur radio, specifically a VHF/UHF radio, what filters are on-board?
I don't know that they need them -- they're factory filters if they exist at all (besides a high 'Q' circuit, here and there).
OTOH if you're experiencing near field stuff that's unwanted (ever hear a pager come over a VHF repeater, unintended?) then it might be beneficial to reject such signals.
'adjacent channel' stuff (rejection I think) comes to mind. I haven't read any sales literature, lately.
If you're on a crowded band and there are strong signals nearby (not on your frequency, but close to it) then some filtering might be desirable.
There are all-mode VHF rigs, and probably UHF rigs as well. CW is CW; if it's crowded at all, then filters are a good idea.
In a power supply, why is there a filter followed by a regulator?
The classic lineup is transformer, rectifier, filter, regulator. The output from the rectifier is just half the AC waveform (so it's zero half the time) for half wave rectification, or the AC waveform with the negative peaks flipped to positive (so it's zero between peaks, same as AC) for full wave rectification.
Because of this, the regulator would have zero volts input part of the time, which won't work: the input voltage to the regulator generally has to be positive, and for a linear regulator, above the output voltage. The filter accomplishes this by storing voltage to ride through the zero periods from the rectifier. There will still be "ripple", but it won't go down to zero any more, and the regulator will vastly reduce the ripple, giving a clean output.
So the filter helps with maintaining that 'straight' DC output as demonstrated by a straight line on an oscilloscope?
And then the regulator reduces that voltage to a lower output voltage?
Right, and smooths it out further.
So without the filter, the voltage won't be a straight DC voltage and there will be some instability?
Yeah, you'll get a lot of buzz (if it's an audio circuit), and possibly even squegging.
A little while ago we were talking about modulation like SSB, FM and AM and a little bit of CW. What is PM?
I've been having an issue with the RFM 69 breakout board from adafruit for a long time now (link to it is here: https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/overview). I already asked this question in several forums but didnt get an answer so Im coming here now.
Im following the guide series at the link, my wiring, code and library is equal to what youve got there. THe only difference is that I am using an arduino Nano instead of the board shown in this wiring diagram I am following: https://learn.adafruit.com/assets/40615. However the init function from the radio head library keeps failing no matter what i do. I exchanged the whole hardware rewired everything multiple times nothing helps. After messing a bit around with the library code i found out that it fails at the part where it is supposed to get the device version, namely:
// Get the device type and check it
// This also tests whether we are really connected to a device
// My test devices return 0x24
Serial.println("Obtaining device number");
_deviceType = spiRead(RH_RF69_REG_10_VERSION);
if (_deviceType == 00 || _deviceType == 0xff) {
Serial.println("No valid device type found, is a device connected?");
//return false;
}
Serial.println("Done");
(serial prints are by me)
Which as you can read in the comments means that there is either no device connected or the board is just not returning a valid one. If anybody knows a thing i could do or knows a person who might be able to help me, please tell me
I believe that's the initial transaction and it seems to be failing, so I'm guessing an SPI problem. That in turn can be caused by a few different things, such as clock frequency issues, pin contention, initialization, and (of course) wiring goofs.
Could also be a voltage issue (is the Nano a 3V device?) or a hardware issue. Figuring out what's really going on can be a bit of a slog, doing a bunch of tedious checks on things. So I'll lead off with some obvious-sounding questions: do you have a multimeter? An oscilloscope? Another SPI device? Another CPU? If you don't have any of these things, you can do some basic testing with just an LED, resistor, breadboard, and some jumper wires.
ok ill try that, thanks you are the first one answering after like a week
@cold viper also, check your wire length and baudrate. During the CircuitPython library work, it was discovered that longer wires weren't handling higher baudrates.
im already using the shortest wires i got so i hope thats not the problem
Just a mention for a possible "try". 1-10kHz worked at times that 100kHz didn't.
In my experience, there are a bunch of helpful people on this discord, with a variety of knowledge and experience. However, people are often busy, so replies may take hours or days, but generally you'll get good help here. I am all too familiar with the frustration of fighting the same issue for a long time (my time circuits bug had vexed me for over a year), and asking for help and getting no answers, so I try to at least check in here from time to time in case there's something I can offer.
i just tried with another SPI device (namely a SD Card adapter) and it worked perfectly no spi issues whatsoever
and thanks for that tip
Ah, that's useful information! That tells us that the issue (likely) isn't with the SPI port, pins, or support. That means we can skip all the testing for pin mode, I/O pin driver health, etc.
My usual response to debugging issues is "divide and conquer", which usually boils down to trying to eliminate possibilities and then concentrate on what's left.
what are the possibilities i should try to eliminate here in your opinion?
I don't think it's a voltage issue any more (I wasn't familiar with this breakout, so I read up on it, and it includes support for 3 and 5V logic, so it shouldn't matter which voltage your Nano uses.
You're using the Radiohead library, which is pretty solid.
yeah, even the fork by adafruit
At this point, I'm thinking either a low-level SPI issue, a quirk with your Nano, a wiring goof, or a problem with the LoRa breakout itself.
Not a hardware failure with the Nano, but perhaps a pin mapping issue, so the pins you're using for reset or chip select might not work quite the same way, or the voltage you're using for power isn't the same as the I/O voltage.
I guess the wiring goof issue is the easiest to check?
Your SD card test (a great idea, by the way) pretty much tells us that SS, SCK, MISO, and MOSI are okay, but that still leaves the reset pin or a voltage issue. I'd probably eyeball those first.
Doing a low-level test of SPI communication is what I'd try next, but it's a pain (basically emulate SPI by bit-banging the I/O pins and printing out what happens).
Looks like you can just try disconnecting reset, it should be pulled high by the board
Also, if you're running a 3V Nano, you'll also want to run 3V to the Vin pin (not 5V like in the diagram)
nah its a 5V nano
Okay, not an I/O voltage issue.
yeah so just wired it again and flashed the code, still init failed
so not i wiriing problem i hope
Hmm, probably time to look at the software. What does your init line look like? Mine looks like this: ```#define RFM95_CS 8
#define RFM95_INT 3
static RH_RF95 rf95(RFM95_CS, RFM95_INT);
#define RF69_FREQ 433.0
// Singleton instance of the radio driver
#define RFM69_INT 3
#define RFM69_CS 4
#define RFM69_RST 2
#define LED LED_BUILTIN
RH_RF69 rf69(RFM69_CS, RFM69_INT);
int16_t packetnum = 0; // packet counter, we increment per xmission
void setup()
{
Serial.begin(115200);
//while (!Serial) { delay(1); } // wait until serial console is open, remove if not tethered to computer
pinMode(LED, OUTPUT);
pinMode(RFM69_RST, OUTPUT);
digitalWrite(RFM69_RST, LOW);
Serial.println("Feather RFM69 TX Test!");
Serial.println();
// manual reset
digitalWrite(RFM69_RST, HIGH);
delay(10);
digitalWrite(RFM69_RST, LOW);
delay(10);
if (!rf69.init()) {
Serial.println("RFM69 radio init failed");
while (1);
}
just the code from them with other macros
Hmm, that looks wrong to me. I think the reset pin is active low, so that could would try to initialize it while it's being reset.
Try swapping LOW and HIGH in the lines where it's driving the RFM69_RST pin.
I figured it was worth a try.
Yeah, I think that is next. I don't want to waste your time with untested code, and I don't have an implementation handy, so I figured I'd try to bash something together here to make sure I understand it and have working code, then share it with you for you to try.
I don't have a nano or that breakout board, so I figured I'd try it with an ordinary LoRa shield and Arduino, it's just some of the pin numbers might be different.
i assume I'll need some meassuring equipment for that SPI thing which i dont have here but i know somebody irl who i can ask for help with that. But thats not going to happen that soon so leave yourself time for testing your code and ping me when you got everything done you need ok?
Nope, this will be a software-only test. I'm going to put together a simple program to do an SPI transfer a bit at a time, and print out what it's sending and receiving.
oh thats great
This initialization step is pretty simple, it sends a single byte (RH_RF69_REG_10_VERSION) and receives a single byte that should be the device version.
so you'll just send that yourself and see what happens?
So I'm going to emulate just that transaction and see what happens. SPI is a funny protocol, it sends and receives a single bit with each clock. So what it's doing under the hood is sending 8 bits (and receiving 8 bits, which it ignores), then sending 8 more bits (which are ignored by the target) and receiving the 8 bits that are the reply.
So I'm going to do exactly that and yes, try it myself on this LoRa shield to verify that what I'm attempting is actually working.
Okay, got the code written and compiled, time to plug in the board and give it a go.
Sure enough, I get 0xff. Now to figure out why.
at least that means Im not alone with my issue
Realized I left out the select logic. Added that, getting slightly different results, but not the correct results. Now perusing the RFM69 data sheet looking for clues.
I may break out the oscilloscope to see what's really happening (I'm making a few assumptions on pinout, since I haven't used this board before).
I may have figured out what's going on. You may be using the wrong driver for your chip. The LoRa chip is the RFM96, the RFM69 is a different chip (an ISM transceiver).
It just so happens that the RFM96 uses register 10 as the RSSI threshold control register, which contains a default value of (yup!) 0xff. Whereas the RFM69 uses that register as to hold a chip version number, which is what the driver is looking for.
But the code you pasted read RH_RF69 rf69(RFM69_CS, RFM69_INT);
yes
because i assumed im using a 69
all the time
and the subpage i got that code from says
and the chips have RFM69HCW printed on them
Oh, how confusing. The chips have a common pinout, but the software required to run them is different, and I'm guessing the software you're using isn't the right software for the chip you have.
so the adafruit docs on their own chips are wrong?
i mean i can try the rfm96 very quick and see if that fixes it
Sort - of. It appears that there are different breakout boards. If you go to the "RFM9X Test" section, it shows how to use the 9x series chips.
That said, if you want to play with the code I wrote, here it is:
Software SPI test code
I'd suggest trying the RFM96, since that matches the markings on your chip (and you said it's a LoRa board: the 69 chips are a different kind of radio).
In that case, you may have the wrong board 😦
why print rfm 69 on a not rfm 69 board
It could be because the two chips have a common pinout, so the same board serves both of them. You're saying the board itself is marked RFM69 and the chip is RF96?
no
the chip is supposed to be 69
thats why i am confused by your conclusion
like i ordered a 69 and now you are telling me it might be a 96
When you said "wait so the chip here infront of me is in fact an rfm96", that's what makes me think you've got the other chip.
I'll admit to being somewhat confused.
yes same here
I wonder if I have an RFM69 lying around.
It just so happens that the RFM96 uses register 10 as the RSSI threshold control register, which contains a default value of (yup!) 0xff. Whereas the RFM69 uses that register as to hold a chip version number, which is what the driver is looking for. this made me think its an rfm96 because i read in the lib that a return value of 0xff would cause it do fail the init
Sorry about that.
After some rummaging around, I dug up a Moteino and an RFM69 Feather. I'll do some basic testing on that.
Okay, I can read the version register on the RFM69 with my software SPI code and get the expected value.
okay
in that case ill try that myself too. Im assuming the SS ping is for the chip select one on the rfm?
Yes, SS "slave select" is the SPI term for "chip select".
sending request for version
sending request 0x10
sending byte 0x10
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 1
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
received byte 0x0
getting response
sending byte 0x0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
received byte 0x0
got response 0x0
sending request 0x42
sending byte 0x42
sending bit 0
received bit 0
sending bit 1
received bit 1
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 1
received bit 1
sending bit 0
received bit 0
received byte 0x42
getting response
sending byte 0x0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
received byte 0x0
got response 0x0
im getting this with the code you sent
is that good?
That tells us some things. Sure enough, reading register 10 (the version register) does not return the expected result.
Interestingly, the read from register 0x42 gets 0x42 back, which sounds like a weird data coupling issue (a clue!)
\o/
Trying to figure out the best way to determine if MISO is being driven correctly. My thoughts so far are try grounding the CS input, and hooking an LED and resistor to MISO to see if it's getting driven.
so CS from arduino to ground and an LED plus resistor into the MISO line?
Disconnect CS from the Arduino and connect it to ground (don't ground the Arduino CS pin), then run the sketch again and see what happens.
alrighty
stuff has changed
software bitwise SPI test
sending request for version
sending request 0x10
sending byte 0x10
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 1
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
received byte 0x0
getting response
sending byte 0x0
sending bit 0
received bit 1
sending bit 0
received bit 1
sending bit 0
received bit 1
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 1
sending bit 0
received bit 1
sending bit 0
received bit 0
received byte 0xE6
got response 0xE6
sending request 0x42
sending byte 0x42
sending bit 0
received bit 0
sending bit 1
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 1
received bit 0
sending bit 0
received bit 0
received byte 0x0
getting response
sending byte 0x0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
sending bit 0
received bit 0
received byte 0x0
got response 0x0
Oho, the plot thickens! That looks like a response, but not really the expected one.
Maybe try uncommenting the #define CLK_ACTIVE_LOW line and running it again?
k
Maybe comment out the #define VERBOSE line if you don't want to see all the individual bits.
software bitwise SPI test
sending request for version
sending request 0x10
sending byte 0x10
received byte 0x0
getting response
sending byte 0x0
received byte 0x0
got response 0x0
sending request 0x42
sending byte 0x42
received byte 0x3
getting response
sending byte 0x0
received byte 0xC0
got response 0xC0
Try running it again and see if you get the same numbers.
sending request for version
sending request 0x10
sending byte 0x10
received byte 0x0
getting response
sending byte 0x0
received byte 0x0
got response 0x0
sending request 0x42
sending byte 0x42
received byte 0x0
getting response
sending byte 0x0
received byte 0x0
got response 0x0
nope
It seems to me like the MISO line isn't being driven, so it's just picking up random noise. Try disconnecting the reset wire entirely and running it again.
software bitwise SPI test
sending request for version
sending request 0x10
sending byte 0x10
received byte 0x0
getting response
sending byte 0x0
received byte 0x0
got response 0x0
sending request 0x42
sending byte 0x42
received byte 0x0
getting response
sending byte 0x0
received byte 0x0
got response 0x0
just 0s
It's really starting to look like you have a broken module 😦
that is shocking
in fact my friend ordered these two (we had others before which didnt work either) just to verify that we dont have broken modules
they are barely a week old
Hm. Seems unlikely then. Well, let's keep going, shall we?
sure
Try it again with the reset lead connected directly to +5V (run it a couple of times to see if the numbers change), then again with it connected to ground (again, not connected to the Arduino).
1st ground all 0 2nd same 1st 5V 0 2nd same
or
should i rewire all that miso and CS stuff first?
Perhaps time to try the LED. I'd like to try the LED two ways, once to +5V (to see if MISO is pulling down at all) and once to ground (to see if MISO is pulling up at all).
so ill just leave the wiring as is now and put an LED in the 5V and the GND line (just want to be sure im not doing things wrong as im not particulary into electronics)
Right. The wiring changes are to eliminate other possibilities.
So one lashup is +5 to a resistor to the LED anode, and connect the LED cathode to the MISO pin.
The other way has the MISO pin to the resistor, to the LED anode, and the LED cathode to ground.
Then run the sketch a few times, peering at the LED. It may stay on or just flicker briefly when the data is flowing (you may need to dim the lights to see it, or slow down the code).
Interesting, so it is being driven. Does that change any if you change the reset line?
Yeah, but the short flicker indicates it's sending data (which is what we want).
ok and
if i remove rst it still stays on for the +5v
so its sending data
does that mean we can be sure its not broken?
Not for certain, but signs are good. The trick now is to figure out why the data it's sending isn't getting picked up at the Arduino end.
Remove the LED and resistor, and disconnect the MISO wire from the RFM board to the Arduino, and connect that Arduino pin to +5V and run the sketch. The expected result is to get 0xff for all the replies.
So the board can send and the Arduino can receive, why doesn't this work?
We've eliminated most of the possible variables by now.
Go ahead and disconnect the wire from 5V and reconnect it to the MISO output of the RFM board, then go back into the code, comment out the #define CLK_ACTIVE_LOW line again, and re-run it.
I'll admit it: I'm stumped here. Everything I can think of checks out. But it's not working.
Any chance you're in the Baltimore-Washington area? It's about time to break out an oscilloscope.
Oh, maybe we can get them to bring it over (or you could bring your setup to their place).
Right. We've been banging on this for a while.
yup
just to be sure i did everything correct
your macros
// LoRa low level SPI test
//#define DRAGINO
#define RST_ACTIVE_LOW
//#define CLK_ACTIVE_LOW
//#define VERBOSE
#define RFM69_MOSI 11
#define RFM69_MISO 12
#define RFM69_CLK 13
#define RFM69_SS 4
#define RFM69_RST 2
#ifdef RST_ACTIVE_LOW
#define RST_ASSERT LOW
#define RST_DEASSERT HIGH
#else
#define RST_ASSERT HIGH
#define RST_DEASSERT LOW
#endif
#ifdef CLK_ACTIVE_LOW
#define CLK_ASSERT LOW
#define CLK_DEASSERT HIGH
#else
#define CLK_ASSERT HIGH
#define CLK_DEASSERT LOW
#endif
#define RH_RF69_REG_10_VERSION 0x10
and my pins from arduino to rfm
5V -> VIN
GND -> GND
D3 -> G0
D13 -> SCK
D12 -> MISO
D11 -> MOSI
GND -> RST
Looks right to me. And the fact that you can talk to an SD card tells me that SPI basically works.
sigh
@primal warren earliest i can get access to an osci is next week so we'll have to wait until that
Sorry about that. Usually these problems aren't so fraught with mysterious complications.
I may take an oscilloscope to mine and see if I can glean any more details about how it's supposed to work.
@primal warren unfortunately the guy with the oscilloscopes has only got time during our morning which means night for you so I guess you couldn't really tell us what to do then. The only solution I see for this (tell me if you've got a better idea) is that you write up what we should do and I tell you about the results later the day
Perhaps I'll make some measurement of mine and send you the pictures, so you can compare what yours looks like.
@pliant garnet that is phase modulatution
Is is just another modulation for amateur radio? Is it even used commonly?
@pliant garnet I don't know if it is used much except maybe in digital modes
Ohh, ok, thank you for your help.
@pliant garnet the wikipedia article on the UART says simplex is one-way communication without expectation of a reply.
It says sharing a channel and taking turns transmitting and receiving is half-duplex; talking at the same time (both talking, both listening) is duplex (or full duplex).
In common use, simplex on 2 meter FM is direct communication on a single frequency -- requiring push to talk in order to hear the other person (can't just key down forever).
Right.
push to talk could be considered half-duplex according to that USART article.
Also to muddy the waters further, there are antenna systems that allow unexpected things to occur.
duplexer is a term you will hear.
I've put snubbers (diodes) back to back across a receiver's antenna, so that I could listen on that frequency while transmitting on it. ;)
That requires a separate antenna to do that -- either that or (on some higher bands) the duplexer I just mentioned can be used (or so I've heard).
I'm pretty sure that's how repeaters work -- the duplexer allows them to hear at the same instant that they transmit (thus allowing the repeater to amplify and retransmit the incoming signal at the same instant, rather than by some amount of delay).
Pretty sure they can use the same antenna, with the duplexer device. Which I don't quite understand, though I suppose I know the general ideas involved.
Repeaters on 2M FM usually are on 600 kHz splits (.19/.79 or .28/.88 are two examples).
Yeah.
That 600 kHz separation from the repeater's input and output is probably enough relief to allow a good notch filter to operate correctly (to reject the very strong 'nearby' signal of that very repeater, by its receiver).
@restive fjord Hey, welcome back. I think people were asking about you and you may have been rigged for silent running for some time.
@rapid hearth Thanks!
I'm never really gone. I have been coding constantly since my last presence here.
ah, genius at work. do not disturb.
@restive fjord I was the one asking about you. was wondering if you were ok
computers are a specific variety of radio. ;)
Does anyone have a favorite RF + Servo combination they recommend?
anyone have good design techniques/tips on creating RF filters at HF ham radio bands (160,80,40,20, and possibly WARC) that require minimal if possible no manual tweaking at all
like, high tolerance SMD components, or at least slugged inductors and no crappy spinny air gap capacitors
@blissful zodiac pretty sure that the Ham 50 MHz band (6 meters) was the frequency of choice for radio control of model airplanes with homebrew transmitters, in the early 1970's or just a bit before then.
With the advent of microelectronics (moving away from discrete components such as 3-leg transistors in a metal case) things have probably changed enough to make that recommendation outdated. ;)
Also fire departments were, I think, centered near 30 MHz (Ham 10 meter band would be comparable) for good propagation in the ranges they operated on. They moved up to 2 meters (145 MHz spectrum) and many are still there.
But that's with repeaters -- I don't know if they had 30 MHz repeaters!
@tiny dust i doubt you're going to find one with those requirements. At least I have never heard of any
I am not familiar with DDC. Direct digital conversion radio?
digital downconversion yeah
basically a really fast ADC
that's one way to not deal with fiddling with handmade inductors
Ah
@restive fjord Around my area some of the bigger departments are changing over to 800MHz digital trunking systems now. The rurals are still running on 2 meter repeater. Good to see you around again! 73s, KI7LNA
@subtle helm Yeah we have some apco25 (is that the name?) around here, but 145 MHz is usual in (fairly flat, low building) cities in Connecticut. 460 MHz (iirc) is highly utilized for business.
I hear 1.2 GHz traffic (iirc, been quite a while now) including some ambulance.
(wa1tnr)
I was also wn1tnr in 1974, and ran CW only at that time. ;)
I used to go to Civil Defense meetings; I think we worked a MARS net there. Tiny tiny shack by the town dump. When I wasn't in attendance, he ran the 'meeting' by himself -- nobody ever came by except other hams who never entered the building.
The one guy I remember who visited that way ran RTTY and I think, later, a packet node.
Civil Defense in the early 1970's was on its last legs in that area. I do not know what became of them; i almost never heard about it from anyone at all. I don't even remember how I became involved. Probably a simple word of mouth suggestion "Yanno, there's a CD meeting at the dump on Wednesdays".
Everything happens on a Wednesday, like that. Weird preference.
Yeah, they also just call it P25, short for Project 25. Out here in Montana they tend to be closer to the 156 MHz range here. They've also got a internet linked P25 system statewide so you can talk back to your local dispatch talkgroup from anywhere in the state, pretty slick...until the internet goes out, then it's back to the Ham HF nets 😛
Has anyone tried FT8call yet?
I haven't.
Does anyone know if instead of buying a LoRa gateway with multiple channels I can simply use another node as the receiver and give each sender an ID so it can differentiate nodes
@limpid citrus What radio's are you using and what Library? The Radiohead library protocol prepends a "header" that allows you to specify an "address" https://github.com/adafruit/RadioHead/blob/master/RH_RF95.cpp#L202
A github'ified version of http://www.airspayce.com/mikem/arduino/RadioHead/ - adafruit/RadioHead
I’m using the Feather LoRa modules made by adafruit with the RFM95, and the Radiohead library
Thanks that helps, just trying to save money because those gateways are expensive
I am reviewing Tony DiCola's rfm_simpletest.py and notice on rfm69.send('xxx\r\n') that the text is delimited with a CR and Newline. I have read the docs and do not find a terminating delimiter. Is the /r/n required or just a nice to have?
@rugged perch The message is just string of bytes - the "/r/n" are just for the convenience of the receiving side.
I often jsut send "data" without any delimeters.
@normal drift Thanks, I understand.
Is there anyone here who has experience with Nordic NRF24L01 modules? 🤔
I'll go ahead and start describing my plight.
I've invested in a few different versions of the NRF24L01 modules. And these are the three types I currently own.
I've gotten a solid connection between two of the NRF24L01+ with the PCB antennas using them with a couple of Arduino nanno clones and the TMRH20 libraries, and the same result with the NRF24L01 PA LNA modules ( bottom picture)
But I've been having trouble getting the shielded module to work at all.
Has anyone ever messed with these before?
I haven't but I'm wondering if you might have RP-SMA antennae.
The antennae that I have are all male. Could that affect anything? @primal warren
They all seem to fit snug.
the issue could be RP-SMA vs SMA. Look into both connectors, if they both have a little hole and no pin then there is your problem.
@fallen matrix
Nah, the antennae are good to go.
Then I'd suspect a cracked solder joint.
recently got a plutoSDR to make a SDR transceiver for a future cubesat I'm helping build. i can ssh into it, but does anyone have any idea about where the power consumption of the ad9363 or arm processor on it? (Xilinx Zynq Z-7010)
The ad9363 is "/sys/bus/iio/devices/iio:device1" but there's nothing for power or current under there, only voltage. any ideas?
Page 11: http://www.analog.com/media/en/technical-documentation/data-sheets/AD9363.pdf it's variable depending on the frequency/power of course, but looks like maxing out around ~660 for the chip alone. (not sure what external components may be drawing)
~660 mA*
ok definitely some progress on the Pi LoRa stuff
that's a node form the learn guide I launched, talkin to a pi
Sweet!
thats a big deal for me, ngl
all I had to do was watch some videos about LoRaWAN. TLDR: The the protocol makes the frequency jump when joining, to get a better join req. The LMIC library also starts it on a subband, so it jumps between channels.
so i remember someone saying that you can use a LoRa for about 20km away from each other, and they still talk to each other, which LoRa is that ? 😛
That 20km figure would be pretty hard to achieve. ;)
@dapper valve it definitely requires some power and a friendly environment...but it seems to hold up. [anecdotal] evidence: https://gridlocate.com/blog/lorawan-20km-range-test/
Yeess thanks
“Your mileage may vary” 😉
@dapper valve It's more like 2->10Km. Certain antennas have claimed 20km
One guy (unconfirmed) pinged the adafruit factory router from governors island
should host a contest lol
haha yeah 😛
Picked up a HackRF a few weeks ago, anyone have any good recommendations for an antenna analyzer and/or a power meter? Wanting to learn more about RF stuff so wanted to set up a dummy load and test some RF circuits, but didn't want to go "too crazy" cost wise for this hobby. (got a million others ;D) Also want to see what these eBay antennas are tuned to, and if they're anything close to their "specs". 😃
Found this and looks tempting, especially for the cost: https://www.ebay.com/itm/New-83-5-4300MHz-Spectrum-Analyzer-W-RF-Signal-Source-For-WiFi-BLE-LT-GSM-GPRS/382426504414?_trkparms=aid%3D111001%26algo%3DREC.SEED%26ao%3D1%26asc%3D20160908131621%26meid%3Dbdc19fa34f4f49f4900fe59ff783a5aa%26pid%3D100678%26rk%3D1%26rkt%3D15%26sd%3D382426504414%26itm%3D382426504414&_trksid=p2481888.c100678.m3607&_trkparms=pageci%3Ac433f25b-c736-11e8-8734-74dbd1804d89|parentrq%3A3b1a3b461660aa16e054cfa5fffb0412|iid%3A1
you want a VNA like the AAI N1201SA or something from rigexpert
@young cove @torpid echo looks my grandpa was W7HAV
@slender current Oh neat, you found it.
yup! this site has good resources http://w0is.com/oldcallsigns/oldcalls.html
@slender current Go to the FCC ULS and check to see if that call is available. You might be able to get it as a vanity
It's a club callsign, since before 2010. /deliberately_vague
This is a nice database interface:
http://callsign.ualr.edu/callsign.shtml
One time we were out for a drive in the family's car, and I had my mobile mag-mount antenna on the roof, working 2 meter repeaters in the area. I put my brother's wife on the air; she enjoyed it very much (this was before cell phones were in common use).
Years later she referred to it as Hand Radio
@silver marten yup looks like its taken. I should probably get licensed and then try to convince them they should give it up
That's unlikely -- look at the city name of the present holder.
HAV havre get it
Lol
plus, me getting licensed is a big if. I've got too many hobbies
if it was free I'd have reason to do it before it got taken
you're a very nice person and ham radio can use nice people as on the air role models. ;)
Laurel vec tests are free.
Emcomm is a good thing. what are you going to do if the cell towers go out
N7HAV has been available since 1995.
After the W's and K's were fairly well maxed out, the N calls became very prominent.
I think that's the only other prefix I know, come to think of it.
he got it in the 30s I think so its kinda neat to have the special one
I looked -- they assigned 1x2 calls like W7HB or whatever, and it took a while for them to circle around and add in 1x3 W7HAV type calls. Definitely before 1940. ;)
😃
I didn't spend a lot of time getting licensed (I learned Morse while commuting). I eventually upgraded to Extra and celebrated with a vanity 2x1 call.
OU812
small radio, long range :leek:
@vocal veldt Thanks for the TTN guide! -- I just got it up and running - with the OLED! Works great!
@normal drift no problem - there's more to come!
Can you have multiple receiver radiofruit feathers per one transmitter radiofruit feather? I’m making a prop that glows brighter and makes noise when it gets closer to certain objects. Worked fine with one transmitter (prop) and one receiver (set object), but I’d like to have 2-3 receiver objects if possible. Each receiver would be in a different room of a house and the prop would be held by an actor moving around the whole house.
By radiofruit, are you using the rfm69 or rfm95 radios.? If so, there can be any number of receivers, especially if they just want to receive a message from the base. It gets a bit more complicated if they have to respond to the base with an acknowledgment since all will respond and all will "hear" all responses. That can be handled via the Radiohead library protocol since it includes a packet header that can contain a "source" and "destination" address id so a receiving system can tell if the message was intended fo it and where it came from. You may not need to bother with that for your application
I think the RadioHead library (and most of the hardware) includes the ability to report the received signal strength (RSSI?). If you choose a protocol that allows multicast, it should be practical.
Cool, yeah I’m using rfm69. Good to know, putting in an order for a few more and will check back in if I have any questions. Thanks guys
@vocal veldt Got the sniffer going - nice! ordered a few more LORA boards == fun stuff
@vocal veldt Cool! your TinyLora example is working now as well -- I had to make a few minor tweaks to get it to compile but it seems to be working. Let me know if you want the details
@normal drift Were you able to get it working on first-run via ABP to your gateway?
yes
yey
There's a weird tweak, you need to disable the frame counter on the Device itself from TTN
I did not have a problem -- set to 16 bit counter
it'll cause some repeats/history issues if left on, I encountered it after a 12hr inital soak test
let me know if yours suddenly stops transmitting, though
hmmm - it might have
I had to remove the "static" from the contant definitions and remove the include of util/delay --- did you have t do that?
disable frame counter checks -- came back
do you have a "decoder" -- not making much sense of the received payload
changed from "hello Lora" to {0,1,2,3,4,5,6,7,8,9,10} - first time came through as expected -- then not recognizable....
I think the way it is written - the data package is overwritten by it's encrypted self so only the first transmission is correct. -- checking
@vocal veldt yes, that works -- since you only initialize LoraData at the start, it is only sent correctly once then it sends its re-encripted copy. If you recreat LoraData before each send, it goes through the same each time.
Oh, I have a decoder. hold on
If you'r esending plaintext
// Decode plain text; for testing only
return {
myTestValue: String.fromCharCode.apply(null, bytes)
};
}```
I tried taht , but it gave garbage after the first packet.
which?
I was using your repo -- should I go to the adafruit repo
The adafruit one is in active development
I have a few PRs to finish on tuesday (doing school things this weekend) but if you'd like to test on that, it's what we'll release with the guide and for cpy
no, no confusion. I'm glad you're testing 😄
if you hit any radio weirdness with that, i'll take a look
sure will -- thanks for getting this going!
@vocal veldt just a heads up - I can get it to work with a clone of your repo -- but the adafruit repo does not work fro me - no errors, bt no packets received -- I have to make the same changes in each t get it to compile. Maybe I am not getting the right version of things. In any case, I'll keep playing with it -- It can all wait until next week.
@normal drift hm, strange. What changes are you making? The delay?
Remove delay from .h remove static from the const definitions in . cop
Are you building for M0?
Building for 32u4
Ahh. That may be the difference. Different compilers . I’m using feather m0. Minor issue
You’re .cpp has lots of changes from adafruit repo. I have not dug into it.
No need to spend time on it this weekend. Glad to clear up the compiler difference
@vocal veldt It turns out, the Adafruit repo only needed one change to work just like your repo ( the data rate in TinyLora.h was different - change SF7BW250 to SF7BW125 and it now works) so now I am using the Adafruit Repo and it is working well-- I posted some notes to an issue. Thanks again for this.
@normal drift did you encounter an issue where the initial device -> gateway connect took a while (I guess to find the correct freq?)
@vocal veldt There does seem to be a lot of variability - but I did not notice a real problem - I'll pay more attention. Its been working very well for the past day.
Using the adafruit/ repo?
just spent a few hours getting one of my applications to send data via ttn to AIO -- it was a bit of a struggle but works now.
I just reconnected my test 32u4 to the gateway and it doesnt seem to be showing up in the TTN console..again
(ABP isn't great for a few reasons)
I'm using the adafruit repo with your PR#4 applied
you did fix the FULLCH to MULTICH , corrcect, its in your PR, but not in master
yeah, i'm actually using the brentru/ branch
ah
the PR #4 you're referring to is is the one which uses SPI transactions, correct?
don't think it has the SPI transactions -- but I may be confused.
it does but not the correct way 😆
ok, updating master to reflect some of your comments
oh -- now I see it. seems to work!
oooh there it is!
alright, pushed the version with the fixed SF/MULTICH to master
Yeah, you can do TTN->AIO via Paho MQTT
(We already use Paho MQTT Python for the Adafruit IO Python Client)
ah --- I did it via IFTTT but I'll look at the MQTT
way faster with TTN MQTT API -> Adafruit IO Python client
(we'll do something from IO soon)
too many toys 😉
https://github.com/adafruit/TinyLoRa/pull/4 I think you have to take out the arguments in this call
oh nevermind -- you did not make that change -- I thought it was in the PR....
I like being able to set the pins in the call. ...
I'll pull the current master and give it a try.
@vocal veldt pulled master -- made my usual compiler changes -- works fine!
nice! I'm adding in code for channel selection (added sglch, multi/single selector bit next)
@vocal veldt trying latest pr (#10) for Mulitchanel I had to set both channel and datarate for it to work, Is there a default?
dr being SF7BW125 and ch being MULTI
hmm - did not work for me. where is the default set?
I added a new example sketch
in examples/
they're set in setup() before lora.begin() as lora.setChannel(MULTI), lora.setDatarate()
for both or only for single? Single channel is not working for me -- digging...
you need to set both the channel and the datarate before the call to .begin()
ah -- there is no default -- could then be set to SF7BW125 and MULTI if not set ?
and did you update the multichannel example ?
does not look like it. It works if I set them -- when I try single chan -- I don't anything tranmitting on my SDR.
bu the single cha example does not set datarate.
updating this..
also should it call SPI.begin()??
will my TTN gateway see the single channel mode?
only if it's listening to that channel
I must have done something -- THanks for the updates -- I'll keep looking at it.
np.
I'm going to go "dark" for the next week until midsemester projects and midterms are over, I'll pop up when I'm done.
Thanks for taking the time to comment and test :). I'm curious if we could/should include the m0 support and how much space it'd take up
currently looking at ~7.53kb
The real problematic area is the frequency/region plans for TTN
@vocal veldt I hope I have not been distracting you. I think support for M0 would be good -- Good luck with exams -- I'll post any comment to the repo.
Definitely not distracting me
If we can keep it under 8k and support the M0, I'm all for it. That's the size I'd like to use for the lib.
I have a 32U4 feather -- I can try hooking up a radio to it so I can test both versions and a combined one if we get to that.
I've been thinking of ways to generate the freq plans (the MSB of each freq on each ch reg. for the same frequency (i.e: USA9x) is the same but the MID, LSB are different)...
thats convenient! may be workable.
Whlie you are taking exams hopefully I can make some progess on a Python version.
you have bigger problems this week 😉
Hello radio community. I want to use a BME680 with a Feather RFM69 (433MHz for France). For the BME680 gas sensor, it must be kept on. I would like it to run on battery for several weeks, with 4 measurements per hour. Does that seem possible to you?
@ruby roost depending on the size of your battery and how clever you want to get with your programming, it's certainly possible
@trail acorn i look at 2000mAh. But it seems to last less than 10 days. And recharging times are more than an hour.
With a basic temperature sensor, i can do deep sleep between measure. But i'm looking for idea with a gas sensor like this BME680
have you looked at the data sheet to see if has a sleep mode?
I look for the ESP32 (Wifi) , but i will look for the M0 RFM69.
Unless I wire the sensor directly on the battery, all the time, and I do a deep sleep of the feather. this should work.
The m0 absolutely does but I was talking about the bme
The BME is very Low power consumer
someone here probably knows better than me but I think you should be able to turn off the radio and sleep the m0 between reads. Also do you need the reads in realtime or can you record a bunch of reads and then send a blast of data once every 15 minutes or something?
you could also just hook the feather up to one of these:
Yes good idea. No need to send each time i do a measure. Now I'm switching from Wifi to radio because of the energy consumption. But if i can deep sleep the Wifi feather and keep the sensor powered, with a 2000mAh Lipo it should do the job
Good little board if the feather doesn't manage deep sleep. Nice
I still can't decide if I should switch to 433MHz radio, and make a gateway to process the data on my PC, or if everything in wifi goes on battery.
the m0 in the feather absolutely can do a deep sleep, it's just a matter of figuring out how to do it. The TPL5110 would just be easier, but then again it would add to your BOM
🤷
5$ is OK 😃
As long as you don't plan on making more than 10 or so.
Your time is probably worth more than $5
I plan to have like 5 or 6 module with sensor (t°, P, gaz ..... but for some only t°)
5$ is cheaper than big battery
Exchange data in Wifi directly with my PC on the network, or exchange in radio 433MHz and make a gateway 433<>Wifi. Is it the same to code? I mean doing MQTT in Wifi or radio is the same thing, right?
HUZZAH32 with ESP32, datasheet says 150uA in deep sleep. looks great.
I don't actually know much about Lora; I'm just lurking. Someone else should be able to tell you
@ruby roost consider adjusting the charge rate of your feather if you want faster charge times too
https://cdn-learn.adafruit.com/assets/assets/000/032/914/original/feather_schem.png?1465421956
Top right shows you the resistor value vs. charge current. By default it is 100mA but you can probably make it a lil higher than that
@slender current , you around?
@trail acorn for a little bit longer
I'm testing a cp32-m4 and getting cdc but no mass storage; it shows up in system info but no CIRCUITPY and I have a bunch of
CP32-M4: family specific matching fails
from dmesg
using the internal flash for the fs?
No, a qspi flash
can you get a serial connection?
ya
The flash is a W25Q32JV which I added a config for in devices.h; Could a bad config there be the issue?
The W25Q series chip used for the SAMD21 Xplain'd Pro board worked out to the same thing Adafruit did with their chip as it had the same geometry and interfaces.
I was surprised when the code ran, designed for that Xplained board, on Adafruit hardware. ;)
(it was a bad config, wrong memory_type)
hello
can anyone help me with how to use a nRF24L01+ to make a wireless SNES controller wireless on a gamecube
i already have the wired verson working
[22:10] <hatsunearu> i am trying to built a canonical DDC SDR radio
[22:10] <hatsunearu> the problem is my clock is some round number like 75MHz or whatever
[22:11] <hatsunearu> but i believe the frequency resolution goes up according to 1/2^N where N is the width of the numerically controlled oscillator phase width
[22:12] <hatsunearu> so i can't seem to get a nice round frequency from my NCO
[22:12] <hatsunearu> like, if i wanna tune exactly to 10MHz or something
[22:12] <hatsunearu> it's kinda impossible
[22:12] <hatsunearu> im wondering what the canonical solution to this is
[22:12] <hatsunearu> do i just throw more bits at the phase register
[22:13] <hatsunearu> or do i add another frequency shifting stage after decimation to get more fine grained frequency shifting
any ideas?
The canonical solution used to be to divide down to an even submultiple and then use either a multiplier or a PLL to multiply it back up to the desired frequency.
In some cases, another local oscillator would be used to drive a mixer that would then generate the desired frequency.
Ed Nisely's blog has some useful articles on the subject https://softsolder.com/?s=frequency+synthesis
anyone know what happens if i multiply two signals that both have a certain spectral noise density?
@primal warren so you're saying i should have two mixers?
i already have one mixer that mixes the raw rf input with a fast DDS/NCO LO
and it will go through AA filter + decimation
you're suggesting i do another shift after decimation?
As for the noise density question, it depends on the noise distribution and if the noise is uncorrelated.
If I remember correctly, I think the noise does increase, but not linearly, so you S/N does improve.
also i saw some solutions where they just have a huge ass phase accumulator
like 32 bits
which gives a frequency offset that's too small to matter
is it square root of the sums of squares again
Yeah, I think that's the approach Nisely ended up going with: just throw more bits at it to get "close enough".
yeah
i probably have enough juice left over in the fpga
not much going on in there anyways
thanks
The nice thing about FPGAs is it's not particularly tricky to build odd-size registers and the like.
yeah
i'm currently trying to figure out an optimum combination of my PAC LUT input width and output width
currently i have 2x RAM LUTs with 9 bit inputs that also exploits symmetry to get 1 extra bit
so it's 11 bits total
and output width is 18 bits
formulas say my phase spur is at maximum -66dB
and my input ADC is 10 bits
so i'm /guessing/ it's mostly ok
but then again idk, that's a -66dBc tone so who knows
the AM spurs due to limited output quantization is too low to matter i think
18 bits
the other option is 10 bit input width so 12 bits, and 9 bit output width
i dont quite like that the NCO output is lower resolution than the ADC itself
That is awkward. It seems to me that you're into "try it and see" territory.
I'd breadboard it, but that's how I roll.
don't have the hardware yet, lol
not to mention i can't breadboard the low noise RF input stage
Then, yes, sim is the next step!
this is running at 75MHz and this is for ham radio
I was guessing this might be for ham radio.
yeah lol
You write like someone who reads QEX
most homebrew SDRs seem to use NE612 gilbert cell mixers or QSE switching mixers
what's QEX lol
QEX is a magazine for ham radio experimenters
wanted to try and make a cheap and dirty DDC SDR
oh lol
i'm just a young fart who doesn't know what he's doing
also (open) note to self this is a good resource for DDS/NCO https://www.analog.com/media/cn/training-seminars/tutorials/450968421DDS_Tutorial_rev12-2-99.pdf
Ah, useful!
I'm just a tinkerer with years of experience, not a lot of formal training.
i think i'll do my next post on sim results
ah
i don't even have a degree yet 😄
and this is my first RF project
I never quite managed a degree, but I've built various RF gadgets over the years. As you pointed out, low noise RF stages are an animal unto themselves.
yeah
so my schtick is
unlike homebrew ham
i might use some rf op amps
and see what happens
noise performance will be /okay/ i think
decompensated rf op amps
pretty good for HF with gainz
Us homebrewers use everything, nothing is off-limits! I used RF op-amps a while back as gain stages for a high bandwidth fiber optic link. Worked pretty well.
oh yeah those are totally good for those
but it seems like rf op amps are a taboo among hambrew
is that a word
it is now
i saw this SDR design
Pfft, nothing is taboo for me, I'll give anything a try. FPGA direct driving vacuum tubes? Sure!
quadrature zero-IF
NE612
spur perf is kinda ass from my analysis i think
like they drive it with a square wave
so you get 3rd harmonic mix products at -10dBc
The mathematics look interesting, but I'm dubious of the real-world performance.
anyways
the part i didn't understand was
it had a preamp but it was weird
inductor loaded BJT common emitter
but like the input impedance is like 2 ohms
so not sure what's up with that
gotta bounce
good talking to you
73!
73s!!
@normal drift quick q if you're around
yup
Were you getting back the "frame counter: #" serial print when runnign on the m0
I removed the static in front of AU915, EU836, US902, AS920 and the S_Table but I don't see it sending on my M0 feather...
yes - runs just like on the 32U4
weird, mine gets stuck at Starting LoRa... Sending LoRa Data...
are you using a Feather M0 and breakout? what pins fpr RST, CS
oo, might be pinmapping
I just built my same version for 32u4 and it also runs -- tested multichan
Yep, the DIO0 gets changed. I might add two mappings into the example and comment out the M0 one
are you using the M0 LoRa board -- just got one, but have not set it up yet.
too many options 😉
rebuilt both from your latest master -- all good -- thanks!
yay, thank you for the testing and m0 advice
https://github.com/adafruit/TinyLoRa/releases v1 of TinyLoRa is out 📻
@vocal veldt you around for a question?
awhile ago I reported taht when I used your example the "Hello LoRa" string was corrupted by the encryption after the first tranmission. Do you see this?
I modified my examples to repopulate the message for every transmission.
You repopulated loraData?
I was wondering it it was having issue with sending characters vs. numbers since I was testing it with #'s earlier. and it was reading post-first-transmission
te encryption process overwrite the Data buffer with the encrypted data
so the sencond transmission is re- encrypting the encryped message -- it all works, but its garbage after the first pass.
just a se - I'll post my change
here is waht I did ```/************************** Example Begins Here ***********************************/
// Data Packet to Send to TTN
unsigned char loraData[11] = {0,1,2,3,4,5,6,7,8,9,10};
// How many times data transfer should occur, in seconds
const unsigned int sendInterval = 30;
// LoRa Object - (RFM DIO0, RFM NSS)
TinyLoRa lora = TinyLoRa(11,12);
void setup()
{
delay(2000);
// while (! Serial);
Serial.begin(9600);
// Initialize pin LED_BUILTIN as an output
pinMode(LED_BUILTIN, OUTPUT);
// Initialize LoRa
Serial.println("Starting LoRa...");
// define multi-channel sending
lora.setChannel(MULTI);
// set datarate
lora.setDatarate(SF7BW125);
lora.begin();
}
void loop()
{
uint16_t i;
for(i=0;i<11;i++)
{
loraData[i]=64+i;
}
Serial.println("Sending LoRa Data...");
lora.sendData(loraData, sizeof(loraData), lora.frameCounter);
Serial.print("Frame Counter: ");Serial.println(lora.frameCounter);
lora.frameCounter++;
// blink LED to indicate packet sent
digitalWrite(LED_BUILTIN, HIGH);
delay(1000);
digitalWrite(LED_BUILTIN, LOW);
Serial.println("delaying...");
delay(sendInterval * 1000);
}
the inital setting are actually never sent - just placeholders -- the for loop in loop set the actual values.
I used 64 + i -- so they would be ASCII characters
hm, populating that way could be confusing for people. Could you re-declare the array at the top of loop()
strings are a pain in C++ -- I don't think its that simple. You can probably regenerate it with sprintf (if ardunio has that) or strcpy.
I took the easy path --
It's something users have to be aware of -- or change the lib to make an internal copy and leave the original unchanged (probably not a good idea)
yeah, I'm trying to think of an alternative to the for loop char population
basically, need to generate the whole message each time.
sorry -- I mant to bring this up before it got released...
its ok, i've been away for a bit and forgot to address this issue
we'll see if anyone notices 😉
eh
maybe add a call to a library helper function to re-generate it from the loop
what's confusing me is within sendData(), the encrypt_payload function is called but what's built is the RFM_Data package
I have not done enought wit harduino -- must e a simple way to create a string, "on the fly". in C I just use sprintf.
just a sec
it encrypts Data
then copies it to RFM_Data https://github.com/adafruit/TinyLoRa/blob/master/TinyLoRa.cpp#L480
it destroys Data when it encrypts it
yeah
Sending LoRa Data...
Frame Counter: 0
189
delaying...
Sending LoRa Data...
Frame Counter: 1
2
delaying...
Sending LoRa Data...
Frame Counter: 2
137
delaying...
Sending LoRa Data...
Frame Counter: 3
181
delaying```
looking at char[0]
I have to run -- I'll think about it too -- It's great to have this working.
Yet when I place it within the send_data() function, it's the original data (unmodified)...hrm
Where are you checking it in send_data?
prior to the encryption call
@vocal veldt I am not seeing the same thing. If I write the data in sendData jsut before teh encryption, I see it changing every time and agreeing with what Is transmitted.
Might be a good idea to do the first option and create a temporary data value, i'll look into that tomorrow
probably do the copying over within senddata, use framecounte = 0x00 to check against the first run (original value)
I'm not convinced taht is the way to go.
Etiher is should copy it every time or not at all.
them mesage may be different every frame
especially if it contains data
right, sendData(tempData), for example
I think either sendata should make a local copy (wastes up to 252 bytes) or jsut document the behavior and let the user beware
I really dont like the idea of declaring the data within the loop()
taht is normal if you are captuing sensor data
I think the message should jsut be a byte array that si populated in the loop - decalred outside.
yeah, maybe I should write a DHT example when I'm at the office tomorrow to better document sensor sends. And redo the hello lora example for re-population inside the loop
I'll try a few ways to generate strings "on the fly" and let oyu know if I come up with anything.
idk if it has to be generated on the fly, maybe can do a memcpy/strcpy
strcpy would be fine -- or strcat
lora.sendData((unsigned char *)loraData, sizeof(loraData), lora.frameCounter);```
@vocal veldt that worked -- just declare char loraData[11}; in the setup
I'll post an issue to the repo.
@normal drift what if we declare the character array as a const
@vocal veldt not sure I understand. sendData still needs t change it -- I think taht will cause an error -- besides - normally it will be changing.
which character array do you mean - loraData is not const
BTW - finally got it running on my feather_m0_LoRA board -- nice!
Yeah, the only solution aside from setting inside the example I can think of is creating an argument for static or dynamic data sends
but that's really inelegant...
I don't really think it is a problem to set it in the loop -- I would expectd most uses to send sensor data or some changing information, not a fixed string.
@normal drift opened a new branch with the fix, I'm going to set up the HQ router again https://github.com/adafruit/TinyLoRa/tree/fix-encrypt
Great! I’m off for a few hours. I’ll take a look when I get back.
looks like it's good on my end
@vocal veldt what if len(loraData) > 10 ??
I could make it dynamically allocate to the length of data...
Guess I still am not sure why it needs to be changed in sendData at all - do this in the user code where you have complete control and knowledeg of the packet size.
I want to make the user not think about their array in the main code and just worry about the send function and whatever else they're doing, similarly to how IO sends data. I just redid the allocation to resize with DataLength as a commit
OK -- should work fine.
"hello Lora" is 11 bytes a C string has a 0x0 terminator appended to it by the use of double quotes
I'm using a modified sketch right now for the DHT22, but I noted to change it
OK -- storing it in a 10 byte array could cause memory issues...
are you using the latest commit?
Yeah, reducing it to 10byte array would cause a mem issue
trying it now
from fix_encrypt branch
shouldn't the copy go to i < DataLength not Datalength-1? if the array is 11 bytes then go from i-0; i< 11; i++ that will send 11 char data[0] through data[10]
I saw a funny packet with the 11th byte incorrect...
We can't assume the array contains a character string -- it may contain DataLength bytes of information
Right..
other that that, the new version is working fine with a fixed array like the original example.
Yeah, it works with a dyanmic one too (dht22 sensor reads)
good!
since you're selecting bytes in the decoder on ttn
Do you want me to caomment on the i< DataLenght in the issue or have you already fixed it?
just fixed
great - thanks
I think we're good to pull into master and release a v1.0.1 with the DHT example
yes -- do you have a decoder for the dht22?
mhm sec
// Decode an uplink message from a buffer
// (array) of bytes to an object of fields.
var decoded = {};
// Decode bytes to int
var celciusInt = (bytes[0] << 8) | bytes[1];
var humidInt = (bytes[2] << 8) | bytes[3];
// Decode int to float
decoded.celcius = celciusInt / 100;
decoded.humid = humidInt / 100;
return decoded;
}```
Thanks
np!
@normal drift I can't tag you as a reviewer, but you would mind reviewing/okaying if possible?
sure - glad to
I'll pull the PR and run it
do you think 2 sec is a good example -- kind of fast ...
Forgot to change that back from local testing to 30
running out for lunch, be back in 15-20
@vocal veldt Nice Gude!! I had not looked at it in awhile.
Thank you! New pages aren't up yet for the 32u4, I'm doing a final proofread in a bit
I think I am seeing them(in red) -- look good -- the M0 should not be much different
@normal drift started on the cpy port of tinylora, didnt get much done but I'm just setting it up for now
I'd like to address the counter (framecount) as an external value called in code.py rather than internal to the library - lora.FrameCounter (in TinyLoRa) and pass it into the sending method. The user is manipulating it from the file rather than the library, anyways.
thats the main design choice I've made so far -dont know if you agree
If the node (tinylora) is not going to look at the response framecounter. I’m not sure it is worth adding the complication to the user to manage it. It could be an optional keyword that the user can set at init if desired.
I’ll hold off working on my python port. You are much faster at getting things out. There are some good examples for doing AES in python. Let me know if you want a link.
yeah, I'll make it a kwarg
Starting to look at a new project is LoRa a 2 way radio?
If so is someone able to recommend a module? it'll be roughly 600 meters (2000feet) almost line of site
@alpine niche Yep, LoRa is bi-directional
Cool! is 600 meters unreasonable to expect out of it?
Are you having fun with LoRa yet @normal drift?
@alpine niche Of course, a lot will depend on your environment and antenna but 600Meters should be fine.
@urban oyster sure am.
Lol, I might get a LoRa radio at some point, I don't know yet. I have my eyes on some other goodies in the Adafruit Shop.
Well, back to fixing OctoPrint, have a great night @normal drift.
@alpine niche I have not done a lot of range testing but I did a simple walkaround my neighborhood using a The Tihngs Network LoraWan Gateway at home -- My transmitter just has a simple wire and there were lots of buildings an trees. I still was able to get at least 500 M
@urban oyster Good luck with Octoprint!
Lol, it was working fine, but I think I messed it up, I'll know after a reboot. Cya. Have fun with LoRa @alpine niche.
I'm thinking the feather 32u4, with LoRa built-in. Ideally temperature, flow sensor and potentially a servo for flicking a switch
would like a power monitor as well but can't seem to find a decent one for AC
I was using a RFM95 featherwing on a feather32u4 adalogger for that test. I think all the RFM9x's will perform similarly.
Are you using the 433MHz or 915MHz version -- I have 915 -- (in the US)
I was looking at the 915, if I'm not mistaken Canada's spectrum is the same as the states
I have not tried a real range test with 2 LoRa boards -- at least not more than about 50M yet. I hope to do a test this weekend but with the reciever inside I'm not sure what to expect for just wire antennas.