 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Anyone got experience of HC-15 LoRa module?
  Page 2 of 2 |
|||||
| Author | Message | ||||
CaptainBoing Guru  Joined: 07/09/2016 Location: United KingdomPosts: 2167 |
@TassyJim Thanks for this Jim. Mick had already said as much - I was totally ignorant of that as I have never been into the HAM scene and so not exposed to such knowledge - just highlights the value of forums. I can't see myself being in need now as LoRa is looking increasingly like it will provide. Guarantee if I used two directional antennae it would cook someones doorbell or baby monitor at regular intervals and draw attention. @Mixtel90 in recent years I would seriously consider a laser link if I had complete control of the environment like that (and LoS). Even these cheapie 5mw laser modules off ebay provide very good performance over quite some range. If it's good enough for StarLink... Looks pretty cool while operating too I would love to have done something like that here.  Edited 2025-04-16 20:17 by CaptainBoing |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7778 |
I like that laser system. :) Super el-cheapo. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4988 |
Captain, Lasers in misty/damp/foggy UK ?? All your neighbours can see where the aliens are landing..... Volhout PicomiteVGA PETSCII ROBOTS |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2167 |
tiddly update So I built the remote data logger and used those HC-15 LoRa modules. They are a dream to setup and then become transparent in actual use. Unit is based on three same-size boards on a verocard bus. Four NiMh AAs and a 6V solar panel to charge them.  Obvs, energy use is paramount as the thing will need to run during darkness and dull days FOR EVER and I don't want to be piddling about with batteries etc. By a combination of specially selected voltage regulator, CPU SLEEP, Hi-Side switching and very aware programming, standby power is 250µA - very happy with that - those AAs should last weeks. The thing runs at 5MHz and wakes every 60 seconds (or sooner using WAKEUP) and checks to see if the RTC has an alarm bit set (hourly). It blinks an LED as a confidence check then goes back to sleep without having woken anything else if not required. The LED blink is a 10µF cap charging through a 220kΩ resistor and I simply dump the cap through the LED with a small transistor, so I get a really bright flash with virtually zero energy (one twenty-seventh of 6µA effective continuous draw) Stand-by (mA)  The following activity take places over about 7 seconds every hour: Sensors awake (with only a single sensor shown)  Sensors off, Radio on, Transmitting  Radio on, Transmit wait period prior to standby  a lot of that (and the Tx current is probably down to the mite having to run at 20MHz to service COM2 at 9600 baud - a design mistake on my part... if I had used COM1, it could all have been done at 5MHz  The data is a bit spotty, I am at -134dbm sensitivety and I can hear the data burst on my scanner all over the Rx site but I get some times when I get no data on the Rx... it is right on the edge as when both Rx & Tx are just a few tens of metres apart it is solid, so it has to be a distance thing. I did change to a full-wave whip at both ends but it seems no better than the supplied helical antenna so I will probably go back to that on the Tx end if nothing else it is tidier. As with nearly all radio stuff, it seems to be about the Rx more than anything. I will get it on the bench later today and I will set the HC-15s to -137dbm sensitivity and see if that improves matters. It will require a software tweak as the data away-speed is about half so the warm-down period on the transmitter will need to be increased. The HC-15 provides a "STAT" signal that goes LO when the Tx is busy, but it isn't active for the entire Tx period, just while the module is "processing". It would be nice if it remained LO until the Tx has completed then I wouldn't have to have the warm-down period after STAT goes HI. I need it because I am switching the power off when in stand-by and I don't want to accidentally turn off the HC-15 while data is still leaving it. The sensors are all controlled from a single board and I use a hi-side switch there also as the four soil sensors are hungry (555 based) and as I only need a figure from each once an hour, I switch them off and save their collective consumption of 24mA constant draw is not acceptable. Needs a few tweaks on the bench yet but it has been largely self-running for the last week left out in the garden and is now very close to being let off the leash. h Edited 2025-05-19 20:18 by CaptainBoing |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4988 |
Hi Captain, If you promote them as "easy to set up", I will try them also. Just ordered a set. Just to play with ... Volhout PicomiteVGA PETSCII ROBOTS |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2167 |
Hey Harm, I made a little pass-thru adaptor and glued a toggle switch to the side of it. Now I can plug a HC-15 on one side and into a CH340 USB/Serial adaptor on the other and it is a peice of cake to switch between program/opertional mode. When in program mode, it's impossible to type commands in - it's one of those "terminals" that accepts what is in the buffer as soon as there is a gap between stop and start bits for each byte - which means typing can never keep the flow going. Easy enough to write your commands in an editor then copy the whole line and paste it in the terminal window. I just set both of mine to -137dbm to increase sensitivity as my data seems right on the edge. I have one more to go after that (-140dbm) before I have to get creative with antennae. The whole process on two modules took about 40 seconds. There are 50 "channels" (they aren't single frequencies because of the way LoRa works) and I found only three of them were legal for licence-free in UK; C27, C28 & C29, which is centre frequencies of 433.39, 434.00 and 434.61MHz. I went for the last as it seemed quiet. Monitoring with a scanner, I could hear various occasional chirps on the other two and I have no interest in them trampling all over my data nor I, theirs. C1 is 415.09MHz and C50 is 449.86MHz... play how you like Finding the manual was a bit of a mission - took me a while to kludge the attached together but it contains all the stuff you'll need HC-15 LoRa Module User Manual.zip drop me a line if you need any help, but I found them really easy to work with. h Edited 2025-05-20 00:47 by CaptainBoing |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4988 |
Hi Captain, I received my HC-15 LoRa modules (2 identical units) with antenna's. I connected 1 to a pico, with KEY tied low (in setup mode). Used a little terminal program to talk to it, and being able to set it up. Communication works, but not all commands in the user manual you shared work. AT+B? and AT+P? work. I can check the power and baudrate setting used. Actually, the baudrate is nonsense, since you can only read it when using the correct baudrate. But the other commands (AT+C?, AT+S?) respond with a ERROR: PARAM response. So I cannot see what channel it is set to. Maybe I can set them, but no reply once set. Also : AT does not respond with OK, reponse is ERROR: COMMAND. And AT+V (or AT+V?) cannot show software version : ERROR: PARAM. I fear I have been shipped clone units with barely functional firmware. Ready for the waste bin.... Volhout P.S. the terminal program 'open COM port pico SetPin gp17,gp16,COM1 Open "COM1:9600" As #1 'interactive terminal function print "<ESC> to stop" Do input "command";k$ Print #1,k$ PRINT 'LEN(K$) pause 100 LINE INPUT #1,b$ print b$ Loop Until k$=Chr$(27) end P.P.S.: this website has KEY and STA pin swapped, and even polarity of KEY pin different. website Edited 2025-06-06 23:12 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2167 |
Hey harm. hope you are well. yes your point on the baud and parity is well taken - you only get to check them if you had it right in the first place  As it happens, the defaults (9600,N,8,1) are what I would use anyway so I never visited those commands.To program them, I use putty to connect to the modules with a CH340 USB <=> Serial adaptor. I never spoke to them in "admin" mode from a 'mite. I set them up on a PC and then move them to their permanent home.  note the CH340 and the program switch glued to the HC15 connector. Then I type any commands I want into Notepad++ (my defualt text editor) and copy/paste them into the Putty session... flawless I have to say. Here's my programming setup (ignore the "ERROR:COMMAND" - just me hitting CR to get some space between salient points in the console output) I use the "report" command to determine the settings - thus: AT+RX  I can confirm that both AT+C? and AT+S? work as expected for me with the above setup & method. Any deviations you see must be down to your prog - try putting a semi-colon after your Print #1,k$ i.e. Print #1,k$; without it there is an implicit CRLF which might be confusing things, CRLF isn't necessary as the line is accepted as soon as there is a gap in characters arriving... have to say I don't really like this approach but it does prevent locked up sessions due to partial input so I can live with it. I am confident your modules are OK and its just getting used to the strict input. I have every confidence you'll suss it out. I have bumped into this kind of AT interface before (I think that was on som HC bluetooth modules... maybe HC-05 and they don't wait for CRLF either - you gotta learn to type really, REALLY fast  )hth h P.S. Just like to say that I have found them to be rock solid comms. The Tx is working with the "pigtail" antenna and the Rx has <70cm of single core telephone wire as a "full-wave whip", both vertically orientated - reception is usually the weak point in this stuff. As of this moment, on the latest field test software, I am almost two weeks in with only 3 dropped packets out of approaching 20K... 180m+ through buildings and not much of it LoS. Impressed ... [06-06-2025 15:01:49,PT01,29.5,34.4,1.1,1.0,1.2,0.6,5.4,5.7,1749222107,EE94] [06-06-2025 15:03:06,PT01,29.3,33.5,1.1,1.0,1.2,0.6,5.4,5.7,1749222184,A1D3] [06-06-2025 15:04:22,PT01,29.1,33.6,1.1,1.0,1.2,0.6,5.4,5.7,1749222260,7CB1] [06-06-2025 15:05:39,PT01,28.7,34.4,1.1,1.0,1.2,0.6,5.4,5.7,1749222337,80C7] [06-06-2025 15:06:55,PT01,28.3,34.0,1.1,1.0,1.2,0.6,5.4,5.7,1749222413,B92E] [06-06-2025 15:08:12,PT01,27.9,35.7,1.1,1.0,1.2,0.6,5.4,5.7,1749222490,9D9B] [06-06-2025 15:09:28,PT01,27.5,36.1,1.1,1.0,1.2,0.6,5.4,5.6,1749222566,27AC] ...  two weeks of VBat & VSol - I don't send data overnight, but the latest version caches it until daylight whence it plays catch up a dozen lines at a time... all so as not to draw too much power when we have no potential to re-charge. I have also learned a lot about LoRa... mainly that the protocol ensures you either get data or you don't - I have not seen any corrupt packets, they either come through or they dont. In the example above, that line is 78+CRLF chars long which is two packets (at the settings I am using). Watching it arrive on the console you see the first half then the second after a pause of about two seconds or so. e.g. [06-06-2025 15:12:01,PT01,26.7,36.7,1. <pause> 1,1.0,1.2,0.6,5.4,5.6,1749222719,9CF9] This is why my line is wrapped in [ ] so I can tell I have a complete line to parse. If I get ] before [ I throw it all away... likewise if I get [ after [ etc... What this has all showed me is I don't need my ETX/STX (those odd little "L" characters, or my checksum... checksum is done in the harware. I have also made other changes in the actual data format to save space - multiply everything by 10 eliminates the decimal point etc. and the time stamp at the front is only debug. So this fortnight of watching fairly unispiring console output has paid dividends and the latest software (like to go on this week end will embody many improvements. Edited 2025-06-07 06:51 by CaptainBoing |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4988 |
Yes, I tried every terminatietarieven of commmands Excet: no termination. Monday I’ll pick this up again. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2167 |
Hey Harm. I had some time to play today and can confirm the implicit CRLF is your problem - If I put a CRLF at the end of AT+S? I get "ERROR:PARAM" I am totally convinced your problem is down to the "missing" semi-colon on your Print #1,k$ - Pop a ; on the end of that line and you'll be good to go. Also, for AT+V (not AT+V?) I get www.hc01.com HC-15V1.0 2024.09.30 h Edited 2025-06-08 23:56 by CaptainBoing |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4988 |
Hi Captain, Thanks for confirming. I'll pick this up as soon as I get to the HC-15's. I am glad that my units are sound. Volhout. P.S. It is a bit weird that the commands you give can NOT have a termination, but the response from the module has a termination (I do a LINE INPUT, which returns when getting a termination). Anyway... it is what it is... PicomiteVGA PETSCII ROBOTS |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2555 |
If typing speed is the issue perhaps this from a 'Mite, MMB4W etc. S$ = "AT+V;" : ? #1, S$ |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9570 |
Reading this thread with interest, as I have never played with the HC-15's. Antenna and/or height. Purely as a test one time, I strapped and HC-12 to a stick, and strapped that to the house brick chimney(that was never used), and just used the standard helical soldered directly to the module, and FU4 long-range mode, and I could easily get several km's LOS, just on the helicals. I was amazed at how far you could get, LOS with basic helicals on both ends. Naturally, as you mention, YAGI or other gain antenna would work even better, but yeah.....the whole EIRP rules mean using them is kinda pointless, cos you are breaking the output power rules if you use them with full HC-12 output power - depending on band and rules. Here in NZ, there is a sweet-spot band at 458MHz, which is "Unrestricted" and with a power limit of 500mW, so the Yagi antennas would go really well on or around that frequency!  Smoke makes things work. When the smoke gets out, it stops! |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4022 |
I've met a chip (can't recall which) where it expected a human to be typing commands at it. So, it thought a command arriving too fast with CR LF was a human wanting to interrupt (cancel) the command! A small delay after the command and after each of CR and LF fixed it. John Edited 2025-06-09 18:54 by JohnS |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2167 |
sadly none of the bands on the HC-15s cover that frequency. The highest you get is "C50" which is centred on 449.86MHz From looking at this on google earth with the positions of Tx/Rx set as accurately as I can get it, I am amazed the data is as reliable as it is - 11756 complete lines (23512 packets) with a total of four (!) missing (over 15-ish days). Almost 190m through buildings etc with only a bit un-cluttered. LoS, I can easily believe the claims of "several Km". Putting a full-wave antenna on the Tx made no discernable difference. I will likely re-fit the pigtail on the Rx end and see how it goes. I feel it is important to stress that my setup here is one-way. I do not talk to the data logger (yet). I have a couple of changes to make to the box in the next week (new software, change of diode in the charging circuit) so that will be a good opportunity to try this stuff out in one go. A few years back now, I used scores of HC-12s to switch the lights (and various other tasks) over snooker tables for metering in clubs (was easier than fitting the switch panels with triacs and all the associated gubbins) and they just did what was required so much so that you forget you are using radio. Not a single glitch that was attributable to the radio link. That however was about max 30m indoor and mostly LoS (one site had a mezzinine in the way but didn't make any difference). So I am not surprised what you could get out of them. The HC-12 was my go-to for a short UHF link (and probably will be for an easy hit) and I did consider them for this project but I was scared off by the brickwork in the way over the route. It was a leap of faith (and hope of a simple "cure") in what others were claiming for LoRa that made me go for the HC-15 (UART was a big winner - a lot of LoRa modules seem to use SPI which was a deal breaker on this project)... you have to be more aware of how the radio works - they aren't the simple "stream of bits" you get with HC-12s and you are wise to use the STAT pin to make sure you don't over-run the buffer. By this I mean, with the HC-12, the "away" speed is the same as your interface speed. With LoRa (and more specifically, these HC-15s), things are assembled into packets and the away speed is likely much slower than the interface speed. Without taking note of STAT you could easily just send tons of data and there'll be losses because the hardware cant keep up. That said, there is a 1K buffer on the interface. In my code, I have a WaitSTAT sub which I call before I send and again just before the warm-down period before I switch the power off - I appreciate mine is an "edge case". At the Rx end, you have to be aware that a "line of text" may not arrive as a line, but broken into a number of packets... if your line length exceeds the packet length you might need to have some of your own encapsulation to tell when you can process the line - but LINE INPUT# should work fine. Once you take these changes in approach in hand and write thoughtful/accomodating software, they seem to provide and almost bomb-proof UHF link in demanding conditions. I love 'em and I think they are my new go-to because I don't seem to have to worry about walls and stuff. h Edited 2025-06-10 20:17 by CaptainBoing |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4988 |
Hi Captain, I did get them to work now. Configured them, and ran some test. I did not solder the antenna's on yet, since they are left and right of my laptop on the kitchen table. Configured the power to 0dBm. Channel 28 (also for Netherlands). Made a small terminal program for 2 pico's that each have a HC-15, and started typing. The communication speed between them is really slow. Ideal for you application (once per day a message) but not very useful for larger data transfers. With the settings/setup I have it is around 2-4 baud. But messages don't get lost. I did send larger strings, and every character is ultimately transferred. No losses. That is good. This will be in my list of solutions if ever comes a project that can lives with slow data transfer. Thanks for helping met to get it working... Volhout P.S. I thought to use this for 2 Game*Mites playing a RF connected 2 player game. But the latency is simply to large. I'll check if there are settings that have lower latency (S value) but fear this is not real time enough. Edited 2025-06-11 05:36 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2167 |
yay yes, this is a well accepted trade-off with LoRa - the emphasis is in the range (it's in the name) and the integrity of the data. I have put full wave whips on a pair of HC-12s I use for wireless connections on the console connection (a hangover from the snooker hall thingy) and I can reliably transfer kilo-bytes of program code at 9600 baud over about 30m. As I mentioned above the approach to the radio side is different between the HC-12s we know and love and the LoRa way of doing it. For this current project, range is the key... the payload is tiny - around 60 bytes every 6 minutes so actual airtime speed is not a massive consideration... so long as the data arrives in good shape, it could be via messenger pigeon for all I care Glad you got them working - a new skill acquired and maybe one day it will provide the solution for some long range problem. h Edited 2025-06-11 19:20 by CaptainBoing |
||||
| Page 2 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
