EOS_Lurker

Hey @Tommix, I hope my postings a few pages back haven't mislead you. Although my belief that the NX1 and NX500 "may" have the same processor SoC may be for good reasons, even if this is true Samsung may have permanently disabled features in the NX500. My reasoning basically is that it's a lot cheaper to order one larger production run of a design rather than two smaller runs of two designs. Although perhaps Samsung speed and/or defect-bins their chips into NX1 'premium' and NX500 'sub-premium' chips. Who knows? However, it would be easily for them to laser-cut traces of functional blocks in what I assume/hope is the FPGA and/or RAM, permanently de-featuring the chip. Modern chip manufacture always have at least one laser pass. However, the ARM cores are very, very likely 100% the same. That's why I think software intended to run on the NX1 chip has at least a reasonable chance or running on the NX500. However, Samsung could have also put in some checks in their software which would complicate matters. This could be circumvented using a debugger by someone who has the skills and the time. I'm not sure why my posts got exactly zero traction here, and why someone who has access to the NX1 firmware doesn't at least try to load it onto a SD card and run the NX1 apps on the NX500. It would be easy enough to set up and run, and the results would be low risk and very revealing. But heck, I can't criticize, I'm too lazy to request someone upload the NX1 firmware and try it myself. I barely have time to check this thread every few days. I'm not sure whether these guys who claim to be working on secret projects are blowing smoke or have real skillz to do the job. They'll either eventually either reveal their uber hacks and be worshiped as supermen or slink off into the internet night. I offered some suggestions and got /ignore radio-silence in response, so that pretty much confirms this isn't a place where I want to invest my very limited free time. I avoid making commitments I can't deliver on and would rather play with my new HoloLens - hacking it's API locks is a much more interesting problem to work on and I am very aware of how much time these little hacking project obsessions can suck. I don't see this community growing by what I've seen, AFAIK it appears to be 3-4 guys with unknown skill levels and a bunch of photographers hungrily awaiting updates. Let's just hope these l33t hackers deliver on their implied promises. You might want to return your NX500 instead of waiting. I'm thinking about selling mine to a friend who expressed interest. At this point I wouldn't put money on huge developments unless perhaps a Samsung insider leaks or something - it's pretty difficult to hack hardware of this complexity in a partial documentation vacuum, even for developers with skills.

My semi-educated guess is it's plain old product market segmentation. I.e. if the NX500 has capabilities similar to the NX1, why would customers purchase the much more expensive NX1? AFAIK Samsung uses not only the same image sensor but apparently the same processor & ASIC/FPGA SoC chip in both cameras. Admittedly there is conflicting info on whether this is the case or not, my guess the NX1 just gets a heatsink - whether it's really needed or not is a good question. But it's somewhat likely that the instruction sets for both the ARM core and the FPGA instructions are the same. That's why I advocated trying to run NX1 binaries on the NX500. I also suggested someone try using tizen's kexec command to get the camera to reboot from a bootable image on the SD card - 'if' workable it would provide an easy & safe path to firmware hacking, including getting NX1 features working on the NX500 and a path for diving into the real secret sauce - the code running in the FPGA. Assuming it's not actually an ASIC, that is - there are good engineering reasons for and against both ASIC and FPGA designs or a mix of both. My money is on same chip & using FPGA because it's cheaper and more flexible for Samsung as long as they can keep things relatively power-efficient. I wish I had time to dive in but I'm facing a series software contract delivery deadlines and like to see my kids every so often. All I can do is make suggestions for the next few months. Hopefully Chant or one of the other l33ts will come up with a miracle. But there's a bit difference between dumping binaries looking for ascii blocks, reading the service manual to 'discover' hidden dev menus to change peripheral parameters and really cracking this hardware open for new hacks.

Has anyone tried using kexec in nx_cs.adj to get Tizen to boot from an OS partition the SD card? This might allow us to mod the OS on the SD while leaving the embedded copy alone, reducing brick-risk.

Oh my god, the news on this thread is so exciting - I can't express it in ASCII/UNICODE. How awesome, you guys made my week! 'm a lurker who finally signed up here, just to post a reply: So, I'm a 'prosumer' camera user who purchased my NX500 around christmas (the 'big gift from family') based on the specs & price. My idea was to shoot unattended from an unattended tripod, then crop (& potentially stabilize handheld footage) from 4K to FHD in post. Sadly, once I started using the camera I was pretty disappointed. The 15-minute/4GB limit (still an issue @ 4K if I understand correctly?), and for me especially the lack of manual video white balance control in the NX500 made my results horrible, even worse than my cheap old Panasonic TM-90 (which I know well and still love). This 'forced auto' white balance on the NX500 is killing me! It's tolerable outdoors but absolutely horrible indoors, resulting in unusable orange-on-yellow garbage that's pretty much uncorrectable since the auto-white-balancer is constantly shifting the white balance around... (It seems like such a deal-killer, could I be missing something here?) Having spent the evening reading this thread (I should have taken notes!), I was wondering if anyone has tried running the NX1's .BIN apps on the NX500 camera yet? 'IF' the NX1 video capture app could be made to run on the NX500 that would give us it's manual white balance control (among other things) and to me that would be HUGE. I didn't return the NX500 because it's supposedly a quasi-open-source device and I was hoping something exactly like this would break open. (Plus the fact that raising kids I can't justify spending more... anyway...) Then when Samsung discontinued the product and left us in the lurch, just looking at it sitting on my shelf was kind of depressing. It looked like a device with great potential, intentionally hamstrung for marketing purposes that was going to be a dead-end and a big wasted investment. I was left monitoring developments by searching for 'NX500 firmware' every few weeks... And now these developments... I am super excited and want to contribute however I can. Actually I'm a career software developer with over 30 years of experience. Haven't done much low level hacking lately but know (some) Linux / (a lot of) C++ down to binary optimization (mostly windows) / etc and could probably do some heavy lifting, time-permitting... Not much image processing background, but I think I understand at least the basics. So, from my N00B perspective, and not wanting to brick my (now increasingly valuable!) NX500, I'd like to help (in descending order priority) 1) figure out how to get the camera to boot from the SD card, 2) get the camera to run NX1 firmware (more on this in a moment), and 3) remove the 15-minute 4K video recording time. On the NX1 firm(ish)ware on the NX500 proposed project, the core question seems to be whether the camera is running the same FPGA or if Samsung fabbed different ASIC's for the different cameras. Information seems conflicting on this, with FCC screenshots indicating they're different chips but FFMPEG reporting the same compression engine metadata. So which is it? It seems there's a good argument for both approaches (transistors are cheap vs. FPGA implementation battery run-time might be bad) If anyone can clarify this it seems this would determine whether this NX1 firmware on NX500 project is viable... OR am I missing something here? Admit I've had a few beers tonight... On the 15-minute 4K time limit, it seems like the idea posted earlier of pre-allocating the MP4 files on the SD card is a viable pathway, since probably closing / flushing / opening a new file while straming is problematic and why the limit exists. (Samsung - you could have just supported NTFS, duh!) Or we could somehow just hook the '15-minute-limit-reached' event and re-initiate recording, it wouldn't kill me to lose a few frames (hundreds of frames is more likely :-p). Or at least if the camera could beep a few times to let me know it's stopped recording, that would be a big improvement. Or we could implement NTFS as a supported filesystem, that would be awesome!) One last thing, SAMSUNG - IF YOU ARE READING THIS: Look, you kinda screwed your customers by discontinuing your product line. Sure there are business realities, but I think your sales could have been 50X if you had just completely open-sourced the firmware... Seriously, this hardware has awesome specs and enthusiasts could have made this the cult camera of all time if you had just forked over the crown jewels... (Probably IP licensing issues aside) You could still do that and help compensate your shafted customers. Or at least get your devs to push one more release out, removing all these silly caps. If you're exiting the market, you're not cannibalizing higher-end or newer products! All this being said, I want to end by thanking the guys who have contributed to unlocking the potential this camera holds. Set up a paypal, I'll contribute as well as code! I'm looking forward to seeing how this develops and to contributing as I can. ... Interesting, it looks like the price of this discontinued camera is going UP! If this pans out, folks might want to stock up on Samy cameras before they're gone... ;-)