Search results

The good news is - Init > AT+CPIN?[0D] Echo < AT[0D][0D][0A]+CPIN:[20]READY[0D][0A][0D][0A]OK[0D][0A] That and the rest of the initialisation seems right. Read > AT+CMGR=1[0D] Echo < [0D][0A]+CMGS:[20]27[0D][0A][0D][0A]OK[0D][0A] That seems right; the 27 incrementing to 28 and then 29 as the...

It seems to me that it simply is the case that there can be a delay between sending the AT+CMGS command, it offering up the prompt for the message text, and after sending the message being ready to accept the next command. That's not particularly surprising as the phone needs to check the SIM...

I can't figure it out so what I would suggest doing is going back to basics. Run the PICAXE at its default frequency, forget about the HC12, forget about the LCD, just try to get consecutive SMS messages sent out of the phone. I don't have the hardware to test but this is what I would start...

It's perhaps best to post you full current code and the full output of what you are seeing as it's difficult to tell exactly what you mean, what may be wrong.

Depending on why you need two random variables, and what range of values each is, it may be better to have one variable kicked by RANDOM and just derive two random numbers by adjusting the maths which determines those. For example, two dice - Random w0 : b2 = w0 / 19 // 6 + 1 Random w0 : b3 =...

Funnily enough that's how I discovered my voltmeter battery was on its last legs when I started reading voltages which seemed unbelievably high. I presume it's the familiar 'lowering +V causes VREF to drop which causes VIN maths to make the reading higher'. Took a while though to realise what...

The phone should send on receipt of Ctrl-Z ($1A) and there can be a delay between that and emitting its ready for its next command prompt (">"). A difference could come down to phone firmware, SIM card, even network, maybe simply not waiting long enough. If you swap the phones over you should...

Looks like the phone number is being sent as binary numbers rather than as ASCII characters. I had missed that earlier. I would try adding the '#' to make it the following - hSerOut 0, ( "AT+CMGS=",$22,"+",#b4,#b5,#b6,#b7,#b8,#b9,#b10,#b11,#b12#,b13,$22,cr)

I have usually used something like below to make the number feel more random - Symbol randomNumber = w1 ; b3:b2 Symbol this = b4 Symbol last = b5 Do Random randomNumber this = randomNumber / 17 // 4 + 1 If this <> last Then last = this SerTxd(#this, " ") End If...

I must admit I can forget what I have asked years ago, don't think I have so don't bother searching,, or don't find the actual question if I do. I am always grateful when some kind soul points out it's 'the same as it ever was' and points me to the path I had previously walked.

That sounds more like a piezo than a buzzer. Try this - Do Toggle B.6 Loop Does than male it make some noise ?

Possibly and it may just have been the easy option; allow what is 'output only' to be used as a PWM output leaving the other I/O pins to be easily tri-stated as needed. While it may be possible to tri-state C.0 I can't say I have tried that and there may be hidden gotchas with doing that while...

It's not time which determines if a thing is stable or not but extensive usage with no reports of bugs. It is a bit of a Catch 22 when few have any need to use the beta compilers because the current compilers work just fine for all but a few users. It remains unwise to replace the existing...

For a small number of LED, choosing a larger PICAXE to control one LED per pin and using a ULN2803's drivers or MOSFET's would perhaps be a solution.

If wanting to include a timestamp date in the code downloaded to a PICAXE, there are a few pre-processor expansions which can help with that. Those will save you from having to frequently update the source code, the risk of forgetting to - SerTxd("Today's ISO date is ", PPP_DATE, CR, LF)...

That's hardly unexpected. Windows code doesn't run on native Linux, just as Linux code doesn't run on native Windows, and it can be quite difficult to get anything to run on a non-native platform. One could argue that it's more the fault of tools on Linux, lack of experienced know-how, which...

No it doesn't. But it's great for testing code, to see if it works as hoped for, checking outputs will be doing what they are meant to be doing, before that code is downloaded to an actual PICAXE chip. And, if it doesn't work, it helps the user figure out why not. I find Simulation a great way...

But who is "they" ? It seems to me that Programming Editor 6 is still the same 6.1.0.0 as it has been for a while - https://picaxe.com/software/picaxe/picaxe-editor-6/index.html#download

Having now grabbed the HLW8112 datasheet I am not convinced it wouldn't be possible for a PICAXE to use it but I haven't studied it. I would agree that the HLW8012 is a much simpler chip which is far easier to interface to so would seem to be a better choice.. Looking at that datasheet it also...

I haven't absorbed the full thread, nor read the datasheet, but when it comes to determining a frequency with a PICAXE I too would use PULSIN or COUNT adjusting SETFREQ so units of measurement were shorter time periods. And, if that's not good enough, there are means to measure pulse times...