ay guys! i found this transmission, it seems to be kids transmitting with something on the spanish military band, this happened in Cantabria at 14:05 near Santander
i guess this is illegal right? will it be worth it to triangulate the location and try to alert the parent about it? There seems to be military activity right now with planes flying around here lol
Hey everyone,
Following up on my previous post (Is Shielding your RTL-SDR actually worth it?) :
I finally popped open my custom-shielded RTL-SDR v4 (original USB) to inspect it and compare it side-by-side with my stock v4c (USB-C version).
Even though the official RTL-SDR Blog documentation states that the v4 and v4c are identical in circuit design—with the USB-C connector being the only difference—I actually spotted a couple of noticeable physical differences on the board:
A second transformer / balun: There is an additional small transformer on the board that I can't quite identify the exact purpose of.
- v4 (Micro-USB): Marked NE612A V2005 335VA
- v4c (USB-C): Marked LC8X 436B047 (i guess thats an upconverter, couldn't find docs)
Does anyone familiar with the v4 / v4c board revisions know what that second transformer is doing or what specific IC the LC8X chip actually is?
A few people asked in the comments of the last post about how I built the copper shield for the original v4, so here’s the exact process:
Copper Tape Wrapping: I used several tightly wrapped layers of pure copper tape over the external metal enclosure.
Low Inductance Soldering: I soldered together each layer, turn, and overlap.
The goal was to ensure solid electrical continuity across the whole surface and minimize RF inductance as much as possible (didn't measure exact RF capacitance due to lack of specialized metering tools, but the ground plane bond is strong).
Grounding: When closing it up inside the outer enclosure, the DIY copper shield is directly soldered to both the USB shield ground and the SMA connector shield ground.
Protection: Finally, I wrapped the entire assembly in multiple layers of electrical tape to prevent oxidation of the copper/solder joints and avoid short circuits or cutting myself on sharp solder points.
For whatever reason, this custom-shielded v4 consistently outperforms the stock v4c in my setup, delivering a lower overall noise floor across all HF bands and almost NO birdies on higher ones.
Sorry for taking a while to post this update—I wanted to run it continuously for some time to enjoy the improved reception and make sure there were no issues with oxidation or thermal buildup under the insulation tape.
After opening it up, everything looks spotless and oxidation-free.
Would love to hear your thoughts on the component differences or if anyone else has also noticed board variations between the original v4 and v4c!
*I used AI to polish the English draft of this post since I'm a Spanish speaker and I don't want this post to be a pain in the ass to read.
Don't mind the fcked up soldering lol 😂, it works great anyway
https://reddit.com/link/1u7sx6x/video/cylvmzgi5q7h1/player
Received in Spain is 24/7
And appears in a variety of frecuencies
Idk if thats normal, but it leaks rf without explicit TX lol.
HackRFOne with Portapack H2
Mayhem n_260530
​
​
This is the shielded version
What is that stair like signal? 😉
23:00 UTC Spain
I wanted to share my experience with Turing on a GDM Personalization / AI Quality Analyst project, because honestly it has been one of the most chaotic onboarding processes I have ever seen.
From day one, everything felt improvised.
People were added to Slack channels without clear instructions, some had access to the tools, others did not, some could see the models, others could not, some had Google Groups access, others were stuck for days.
The main thing everyone needed, the so-called Sian Profile / personalization setup, worked randomly depending on the person, the account, the model, the browser, or whatever internal switch someone forgot to enable.
The whole onboarding was a mess:
- Multiple Critical Verification forms.
- Changing model names.
- Conflicting instructions about whether to upload debug TXT files, full HTML files, or Google Drive links.
- People being told different things by different leads.
- Repeated meetings with very short notice.
- Slack channels multiplying everywhere, but nobody giving one clear official answer.
- Some people being allowed to start tasks while others were still blocked by access issues.
Then there is the payment side, which is even worse.
Some people were hired directly through Turing, others through third-party vendors, and the hourly rates were completely different.
People were talking about $20/hour, $15/hour, even around $11.50/hour depending on the vendor. On top of that, Jibble time tracking was a complete mess.
Some people were told to log hours, others were told to delete them. Some had the right Jibble project/activity, others did not. Some were in the Jibble Slack group, others were not.
Later they introduced an AHT model, where you are paid based on the “approved handling time” for each task. In practice, if you complete a task faster, you log less time and earn less; if it takes longer, your pay is capped unless extra time is approved.
So the incentive becomes absurd: work fast and get paid less, work carefully and risk going over the cap.
The tooling itself was also broken. The labeling tool and autoreviewer constantly failed for ridiculous reasons:
- HTML links being read as binary files.
- Prompt match failing because of hidden JavaScript data.
- The reviewer detecting the wrong first prompt inside the HTML.
- Scores changing after running the same review again without modifying anything.
- Tasks failing because of whitespace or formatting issues.
- Confusing instructions about whether to paste raw HTML or a Drive link.
At one point, production was paused because “1P Sources” were appearing in debug information.
From what we could see, internal/private information was being exposed in the debug output.
That is a serious privacy and security concern, not just a minor workflow issue. The batch was paused, people were told to stop claiming tasks, and many of us were left wondering whether the work already done would be paid.
The review process was another nightmare.
Reviewers started sending tasks back as rework, sometimes based on criteria that had not been clearly explained.
For example, people were told during training to use example prompts as inspiration, then later got penalized for using prompts too similar to the examples.
Some reworks seemed reasonable, but others felt completely inconsistent with the instructions we had been given.
And now, to make it even more absurd, I am receiving emails in my personal inbox containing information related to other people in onboarding. That should not be happening. It adds to the feeling that the whole operation is being held together with duct tape.
The worst part is not even one single issue. It is the combination of everything:
- Chaotic onboarding.
- Broken access management.
- Unclear payment rules.
- Inconsistent communication.
- Privacy concerns.
- Buggy internal tools.
- Repeated verification loops.
- Rework criteria changing after the fact.
- Personal emails receiving onboarding-related information about other people.
I understand that large AI data projects can be messy, especially when they scale quickly. But this felt beyond normal startup chaos. It felt like workers were being onboarded before the process, tooling, access control and payment structure were actually ready.
If anyone is considering working with Turing or through a vendor on one of these AI evaluation projects, document everything. Keep screenshots, task IDs, hours worked, Slack messages, emails, Jibble records and any payment-related communication.
Do not rely on verbal instructions or scattered Slack replies.
This has been a complete organizational disaster.
PD: share your links for other jobs, as this is too much of a mess