Recent Posts

Pages: [1] 2 3 ... 10
1
CurrentRanger / Re: CR not auto ranging when using certain test leads
« Last post by noch on July 21, 2021, 09:43:32 AM »
Ok gotcha.  Yeah, these are super cheap leads off Amazon.  I just tested a couple and got 1-5ohms readings and the readings would jump a lot.  Testing a jumper wire and then the leads with the small spring clips I purchased from your store and got 0 ohms.  Reviews on the cheap ones I bought now show others see the same issue with quality.

Thanks! this helps me understand the part of the guide on noise more.  I will hunt down some better leads for sure.

2
CurrentRanger / Re: CR not auto ranging when using certain test leads
« Last post by Felix on July 21, 2021, 09:00:06 AM »
I had fluke leads that failed and I blamed everything else not believing that could happen.
I also had "good" leads that had several ohms resistance.
And this not with the CR in particular, just in general. Bad leads can cause a lot of headache, you'd think leads are just wires and can't fail, but with years of use and wear they can internally tear and  go from useful to causing more damage than good.

In any case, if you use faulty or not very low impedance leads, the CR benefit of low burden voltage becomes offset more or less severely, even at 1 ohm introduced with bad quality leads that is very significant.
Not saying any of this is what you're experiencing, just what happened to me and some ideas to look into.
3
I have some thicker banana plug test leads I connected my DMM to the CR with.  Auto ranging does not seem to work properly when I use these.  When my DUT is in the mA range the CR stays in nA.  If I unplug the leads, auto ranging works fine.  My normal leads work fine with it.  I tried another DMM with the same results.  I am not that concerned with using these particular leads, I just wonder what may be causing this. 
4
Moteino / Re: Problems Using SHT 30-D
« Last post by Felix on July 19, 2021, 10:41:26 AM »
10k should be OK.
5
Moteino / Re: Problems Using SHT 30-D
« Last post by FlyingSaucrDude on July 19, 2021, 09:58:47 AM »
This particular package of the sensor comes with 10KΩ pullups from both SCA and SDL to VCC on its PCB. Could it be that value's too big?  :-\
6
Moteino / Re: Problems Using SHT 30-D
« Last post by Felix on July 19, 2021, 09:53:08 AM »
You have added I2c pullups, correct?
7
Moteino / Re: Moteino r6 hang with bme280
« Last post by FlyingSaucrDude on July 18, 2021, 07:53:29 PM »
EDIT2: soldered a second moteino R6, all works :)

Can you elaborate? I think I'm having a similar problem with a Moteino 8MHz--when I run the i2c_scanner with an I2C device connected (a SHT-30-D temperature sensor) it hangs in the same place. Was it the Moteino that ended up being faulty? Did you have to use flash the regular firmware on the second Moteino?

Thank you so much!
8
Moteino / Problems Using SHT 30-D
« Last post by FlyingSaucrDude on July 18, 2021, 03:05:07 PM »
Hi all! I'm a new Moteino user, and I was wondering if anyone had any ideas about a problem I'm encountering.

I'm trying to use a Moteino 8MHz to read from and SHT 30-D, an I2C-based temperature/humidity sensor. (This one from Adafruit https://www.adafruit.com/product/5064, to be specific.) However, whenever I try to access the SHT30 over I2C using the Moteino, nothing happens. I don't have anything else connected to the Moteino's I2C bus.

More specifically, I've tried several different SHT-3X libraries, and all of them give me an error saying the SHT 30 was not found.

Things I've tried to debug this:
  • I tested the SHT30 by connecting it to my Raspberry Pi Zero's I2C interface, and it worked fine.
  • To figure out if the Moteino has a faulty I2C interface, I hooked the Moteino up to my Pi Zero and ran a slave sender/receiver program. The Pi correctly  wrote and read bytes from the Moteino (which correctly received/sent them).
  • I tried using the simple I2C scanner sketch below to see if the SHT30 would even show up on the I2C bus. Whenever I run the sketch with the SHT30 connected, it hangs at the indicated line. If I disconnect the SHT-30, the sketch runs correctly and reports no devices.

Code: [Select]
#include <Wire.h>

void setup() {
  Wire.begin();

  Serial.begin(9600);
  while (!Serial); // Leonardo: wait for serial monitor
  Serial.println("\nI2C Scanner");
}

void loop() {
  int nDevices = 0;

  Serial.println("Scanning...");

  for (byte address = 1; address < 127; ++address) {
    // The i2c_scanner uses the return value of
    // the Write.endTransmisstion to see if
    // a device did acknowledge to the address.
    Wire.beginTransmission(address);

    byte error = Wire.endTransmission(); // With SHT-30 connected, sketch hangs here on the very first iteration of the loop

    if (error == 0) {
      Serial.print("I2C device found at address 0x");
      if (address < 16) {
        Serial.print("0");
      }
      Serial.print(address, HEX);
      Serial.println("  !");

      ++nDevices;
    } else if (error == 4) {
      Serial.print("Unknown error at address 0x");
      if (address < 16) {
        Serial.print("0");
      }
      Serial.println(address, HEX);
    }
  }
  if (nDevices == 0) {
    Serial.println("No I2C devices found\n");
  } else {
    Serial.println("done\n");
  }
  delay(5000); // Wait 5 seconds for next scan
}

Does anyone have any ideas on what might be preventing the I2C bus/SHT-30 from working correctly on the Moteino 8MHz? Thanks in advance!

P.S. I'm cross-posting this on the Adafruit forums and a couple of other places, just in case somebody elsewhere has encountered a similar problem.
9
General topics / Re: Cloning remote with RFM69
« Last post by Jason on July 14, 2021, 06:19:04 PM »
Hello :)

I haven't messed around with SDR. I do notice in the pictures, that the modulation is set to ASK, where as in the code snippets it shows OOK. I don't think that is your problem though, just something I noticed.

You can probably just "copy and paste" the signal from the radio as you mention and not worry about the encoding. The only potential problem is if they use some sort of rolling codes so the transmission would be different each time. Rolling can be used to prevent people from "copy and pasting" the signal to unlock car doors or garage doors. I doubt a ceiling fan would care, but you never know...

Just my 2cents.
10
General topics / Cloning remote with RFM69
« Last post by cptawesome_13 on July 11, 2021, 04:37:32 AM »
Hello first time poster here,

I bought a ceiling fan for my home office and it is controlled by an RF remote that I want to clone. Using an SDR I have determined that the frequency is 868 MHz and it uses pulse width modulation with fixed period. Since the only radio I have is a Feather M0 I couldn't use Kobuki's sniffer library and no matter how I tried porting it I couldn't quite figure out how to receive the remote signal on the Feather.

On the transmitting side I have tried to match it and came up short as well. This is the rtl_433 output for the remote:
Code: [Select]
Detected OOK package    2021-07-11 00:22:02
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : [color=blue]2021-07-11 00:22:02[/color]
model     : [color=red]Akhan 100F14 remote keyless entry[/color]      ID (20bit): [color=red]0x220fe[/color]
Data (4bit): [color=green]0x2 (Unlock)[/color]
Analyzing pulses...
Total count:   25,  width: 32.32 ms             ( 8081 S)
Pulse width distribution:
 [ 0] count:   15,  width:  300 us [292;316]    (  75 S)
 [ 1] count:   10,  width:  968 us [964;972]    ( 242 S)
Gap width distribution:
 [ 0] count:   14,  width: 1028 us [1024;1036]  ( 257 S)
 [ 1] count:   10,  width:  368 us [368;376]    (  92 S)
Pulse period distribution:
 [ 0] count:   24,  width: 1332 us [1324;1348]  ( 333 S)
Level estimates [high, low]:  15894,    145
RSSI: -0.1 dB SNR: 20.4 dB Noise: -20.5 dB
Frequency offsets [F1, F2]:   -1301,      0     (-5.0 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with fixed period
Attempting demodulation... short_width: 300, long_width: 968, reset_limit: 1040, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=300,l=968,r=1040,g=0,t=264,y=0'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 1
[00] {25} dd f0 1d 80 : 11011101 11110000 00011101 1

And the output for my signal if I set the output to {0x22, 0x0F, 0xe2}:
Code: [Select]
Detected OOK package    2021-07-11 00:22:02
Analyzing pulses...
Total count:   24,  width: 30.82 ms             ( 7704 S)
Pulse width distribution:
 [ 0] count:   13,  width:  300 us [288;320]    (  75 S)
 [ 1] count:   10,  width:  968 us [964;976]    ( 242 S)
 [ 2] count:    1,  width:  132 us [132;132]    (  33 S)
Gap width distribution:
 [ 0] count:   13,  width: 1028 us [1020;1036]  ( 257 S)
 [ 1] count:   10,  width:  368 us [364;376]    (  92 S)
Pulse period distribution:
 [ 0] count:   23,  width: 1332 us [1324;1344]  ( 333 S)
Level estimates [high, low]:  15902,    159
RSSI: -0.1 dB SNR: 20.0 dB Noise: -20.1 dB
Frequency offsets [F1, F2]:    -900,      0     (-3.4 kHz, +0.0 kHz)
Guessing modulation: Pulse Width Modulation with sync/delimiter
Attempting demodulation... short_width: 300, long_width: 968, reset_limit: 1040, sync_width: 132
Use a flex decoder with -X 'n=name,m=OOK_PWM,s=300,l=968,r=1040,g=0,t=0,y=132'
pulse_demod_pwm(): Analyzer Device
bitbuffer:: Number of rows: 2
[00] {23} dd f0 1c  : 11011101 11110000 0001110
[01] { 0}           :

And the two signals on Universal Radio Hacker don't look similar as well:

Top one is the remote bottom one is the Feather output captured by the SDR.

I need some guidance on how to proceed. I believe I'm going wrong with the encoding of the signal (I don't encode mine, rtl_433 says the remote is Akhan encoded). But if I managed to capture the raw signal from the remote with the Feather I could just "dumbly" retransmit it right? And not worry about encoding. How would you proceed?

Thank you
Pages: [1] 2 3 ... 10